My solution was: Set the memory_limit in ./plugins/EmailReporting/pages/bug_report_mail.php' to '512M' instead of '-1'

Oh... please move this ticket to the correct project -.- sorry for that...

ok

ok

Does this stop script execution as a result of this error?

No, it just drop the alert and refuse to set it.

But I think it only refuse because we use suhosin on our webservers: http://en.wikipedia.org/wiki/Suhosin

That means: Some webserver will set Memory_limit to -1 without any warning
-> And that would open a channel for a floating attack (because Mantis can now allocate all memory and the webserver could become unaccessable.

Yes but EmailReporting only changes it for the current page request. Since the script is usually only run through a command shell and not through the browser this should not be an issue (hence the option: "Block this script from running via a webserver (recommended = "Yes")")

And since it only throws a warning but still properly executes the script thats not a major issue either

But i guess setting it to a high value should also have the desired result.

Ok, so normally this script will not run throught the browser. That will make the possible amount of targets lower, but doesn't elimininate it.

Question: Is it necessary to set the value by mantis at all? Because setting it to any fix value could generate other problems (Value is higher than max memory...)

Default is allways fixed to 128MiB i believe

EmailReporting just requires decent amounts of memory when processing attachments so thats why that config change is included

Then it's your Privileg to decide what to do :)

Let me just confirm this

You don't get a warning when memory_limit is set above zero by a script. There is no upper limit to this?
You do get get a warning when its set to -1

I need to decide what to do when the memory limit is reached. We don't want EmailReporting to get stuck on that email and import it multiple times...

I will keep this issue open for a while until i've decided how best to handle situations past the memory limit

I only know, that I receive a warning when it tries to set this value to -1 (Because -1 means "no limit"). Setting it to some other value below 0 is not defined, but I think, that would be ignored.

See also php reference: http://php.net/manual/en/ini.core.php -> memory_limit

You could use this function to determinate the max. memory, that can be allocated by php: http://php.net/manual/en/function.memory-get-usage.php

After that, you can set the value to something lower than that :).

And (to be very serious) you have to check first that PHP-Version is > 5.2.1 (otherwise, memory_get_use is probably not present :)).

Check if PHP-Version is => 5.2.1

That function only shows the memory currently being used by the PHP process, not the maximum it could use

Memory usage is already outputted by EmailReporting when debug mode is activated ;)

Right... I shouldn't do more than three things at one time ;). So you could probably use this for windows_servers:
http://php.net/manual/en/function.win32-ps-stat-mem.php

And that for Linux:
http://stackoverflow.com/questions/1455379/get-server-ram-with-php (/proc/meminfo)

Maybe to big for the EmailReporting-Plugin, better integrate it in mantis core and give plugins global variables to read this values out.

Right that will all help to decide what to set the max memory usage to. But thats the easy part as i could also just give people a configuration option with which they can do this manually

The biggest problem to address is if EmailReporting passes the memory limit set (however high it is) and the script stops execution. Usually EmailReporting will process the email in question every execution since it never comes to the moment where the email is deleted.
Deleting the email before processing it fully is also not an option as it potentially could result in emails being deleted without the user knowing it

maybe just adding a configuration option where the user can decide what the maximum email size is that should be processed. But what to do with the email that passes this size limit.

You could check the size before processing and refuse, if the mail is bigger than the maximum size. (That only reduces, not eliminate the error)

A DB-value where you count the tries on a particular mailobject and stop parsing the email, if the count rise to high? (I would build a key on subject, Sender and some other informations.)

EmailReporting 0.12.1 will introduce a config option for this.

It will need more work though for proper attachment limitations.