Bug#549492: php5-cgi causes segmention fault (fix)
On Fri, 2009-10-30 at 12:11 +0100, Micha Lenk wrote: Hi Vincent, Vincent Caron wrote: I have been able to suppress all my php5-cgi segfaults, I simply installed the 'php5-suhosin' package, reloaded Apache, and done (Lenny AMD64, up-to-date). After having read your comment I've installed php5-suhosin on my server too (Lenny, AMD64, up-to-date), but still got today some php5-cgi segmentation faults: Oct 30 11:21:28 kunden-www kernel: [410275.967073] php-cgi[8559]: segfault at 7f0d4adc7ed0 ip 7f0d4adc7ed0 sp 40a38128 error 14 in libltdl.so.3.1.6[7f0d4b37d000+7000] Oct 30 11:21:28 kunden-www kernel: [410276.004976] php-cgi[8560]: segfault at 7fd44433ded0 ip 7fd44433ded0 sp 423d3128 error 14 in libpam.so.0.81.12[7fd444d03000+b000] Are the segmentation faults I experience something different? How can I find out? I don't really know. I can give more details on how I got a stack trace from gdb on a production server, using Apache2 + mod_fcgid and php5-cgi (with no disturbance): # aptitude install php5-dbg I use the 'FCGIWrapper /usr/local/bin/php5-fcgi .php' directivein my Apache conf and this wrapper looks like: #!/bin/sh export PHP_FCGI_CHILDREN=0 export PHP_FCGI_MAX_REQUESTS=1 gdb -x /tmp/run /usr/bin/php5-cgi 21 | logger -t php5-cgi -puser.info Where /tmp/run is a dumb script to make gdb automatically run, backtrace, then quit: # cat /tmp/run run bt quit Output appears in /var/log/user.log. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549492: php5-cgi causes segmention fault (fix)
Hi Vincent, Vincent Caron wrote: I have been able to suppress all my php5-cgi segfaults, I simply installed the 'php5-suhosin' package, reloaded Apache, and done (Lenny AMD64, up-to-date). After having read your comment I've installed php5-suhosin on my server too (Lenny, AMD64, up-to-date), but still got today some php5-cgi segmentation faults: Oct 30 11:21:28 kunden-www kernel: [410275.967073] php-cgi[8559]: segfault at 7f0d4adc7ed0 ip 7f0d4adc7ed0 sp 40a38128 error 14 in libltdl.so.3.1.6[7f0d4b37d000+7000] Oct 30 11:21:28 kunden-www kernel: [410276.004976] php-cgi[8560]: segfault at 7fd44433ded0 ip 7fd44433ded0 sp 423d3128 error 14 in libpam.so.0.81.12[7fd444d03000+b000] Are the segmentation faults I experience something different? How can I find out? Regards Micha P.S.: I don't know if it matters: I'm running PHP wrapped by suphp. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549492: php5-cgi causes segmention fault (fix)
Good news, I have been able to suppress all my php5-cgi segfaults, I simply installed the 'php5-suhosin' package, reloaded Apache, and done (Lenny AMD64, up-to-date). The backtraces above suggests that the suhosin_patch tries to log some security violation information and lookup some PHP internals which do not seem to be reachable at this point, like the REMOTE_ADDR env used to log the client IP address. Maybe the Suhosin module is vital to setup its security log or something like that (sorry for being vague, I'm talking about intuitions...) Installing php5-suhosin is not as transparent as the doc suggests. I tought this module would only act as a gateway to tune the suhosin_patch which is already built into PHP5 SAPIs. And not change its behaviour upon installation since all parameters in /etc/php5/conf.d/suhosin are commented out. But for instance, on servers where safe_mode=off, the suhosin.memory_limit=0 takes effect uppon php5-suhosin installation and suddenly scripts cannot raise the memory_limit barrier with ini_set(). Maybe I misread the doc, I was a bit in a hurry. are you at all able to reproduce the issue with a simple script (or perhaps by a second script which loops around calling the first until it crashes?) Sorry, nope. I tried a few snippets on a server which should be impacted by this problem but could not have PHP segfault. I can hardly use xdebug on the platform I just fixed, it's very busy and uses a custom and complex PHP framework, I d'ont expect to get any interesting trace there. Hint: my impacted platforms were Etch systems dist-upgraded to Lenny. I'm not sure if it's specific to this criterion, but maybe it's worth mentioning. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
