DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42262>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42262 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO ------- Additional Comments From [EMAIL PROTECTED] 2007-06-25 08:40 ------- (In reply to comment #7) > Hello Ruediger, > > there are no ulimts defined and the physical memory did not go out of limits > during the crash. > A test with defining explicitly 'ulimit -a' before starting apache gave the > same > result. Mind to attach a longer part of the strace of a crashing process? That might be helpful, but to be honest I have to admit that I am out of ideas. > But anyway, if a thread cannot allocate memory, malloc (or whatever function > is > used) should be checked whether the operation was succesful. A > segmentation-fault is to me like a hint to a programm error or at least some > sign for "quick & dirty" hacked code. There were long and controversial discussions regarding this on the dev lists of apr and httpd. The final outcome was that it is better to crash in such situation as 1. there is usually nothing useful that can be done in such a case 2. it offers you the benefit of a core dump and a full backtrace. You may not agree with this, but this is designed by purpose. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
