#21756 [Fbk->Opn]: Accessing $_SERVER['PATH_INFO '] causes intermittent segfault in Apache

ID: 21756 User updated by: php@lost.co.nz Reported By: php@lost.co.nz -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux/Apache (Debian 3.0r1) PHP Version: 4.3.0 New Comment: I sense some degree of frustration here. I had thought that I had given enough details for someone familiar with the Apache/PHP interface to diagnose the problem. Please accept my apologies if that is not the case. I will try to rectify matters now. This is a *very* serious issue, effectively killing off apache intermittantly, and so is worthy of a fair degree of effort to diagnose - I spent three days correlating access logs, error logs, and the scripts that were called looking for common elements, and eliminating possible matches, before discovering the cause (and a work-around). It is especially insidious, as it only seems to cause real problems (ie, failures visible to clients) on a production machine. I use a testbed that is configured the same as the production server in order to test new PHP releases etc..., and everything seemed to work fine, even when stressed by test scripts run on clients. Anyway, here is as much information as I can give you... The requested (short, COMPLETE, and self contained) example script: <?php echo $_SERVER['PATH_INFO']; ?> If $_SERVER['PATH_INFO'] contains a value, this value is echoed, and there is no problem. If $_SERVER['PATH_INFO'] does not contain a value (usually at the frontpage of site) *sometimes* Apache will throw a segfault. I ran gdb on the test server (identically configured to production server), but was unable to catch segfault in action. The intermittant segfault occured in both machines, though *much* more often on the production machine. Examination of old error logs seems to show that problem existed with 4.2.3 as well, but not earlier builds (but I cannot absolutely confirm that). The workaround: Wrapping reads with call to isset() reduced occurance of segfaults from 200-300 a day on the production machine, to zero. eg: <?php if( isset($_SERVER['PATH_INFO']) ) echo $_SERVER['PATH_INFO']; ?> Observations on production machine: The segfaults seemed to increase in frequency over time, untill Apache effectively stops serving pages altogether. I could only observe this effect on our (remote) production system. Restarting Apache seems to settle things for a day or two from a users perspective, though there continue to be segfaults in the error log. Setting the maxrequests config. in Apache had no effect. Most of our websites use the value of $_SERVER['PATH_INFO'] extensively in order produce dynamic content while avoiding use of ugly, search engine unfriendly urls, eg: www.test.com/products/clothes/boys/summer.html vrs. www.test.com/products.html?line=clothes&sex=boys&season=summer which may help to explain why I have experianced this problem, while obviously many others have not. Misc. info: Linux 2.4.20 (Debian 3.01), Apache 1.3.26, php 4.3,0, options: --with-apxs --with-pgsql --with-zlib --with-xml --enable-wddx --with-mm --with-config-file-path=/etc/php --with-gd Previous Comments: ------------------------------------------------------------------------ [2003-02-06 16:59:05] sniper@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip With the very little information you've given..please give the snapshot a try. If the problem persists, please give us a _complete_ and short example script which can be used to reproduce this. Also, what was the configure line used to configure PHP? ------------------------------------------------------------------------ [2003-02-06 13:36:56] php@lost.co.nz I have already tried to generate the requested backtrace (as already noted below...), but was unable to get apache to segfault while I was watching. I determined the cause of the bug by comparing access and error logs, looking at the called scripts, and examining points of similarity. The bug was confirmed when, after I wrapped the reads to $_SERVER['PATH_INFO'] (see below) the segfault frequency went from 1-200/day to zero. This was the only change made, which would seem to clinch the deal. ------------------------------------------------------------------------ [2003-02-04 16:51:06] sniper@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. ------------------------------------------------------------------------ [2003-01-20 04:50:25] sniper@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. There you can find some info how to use GDB properly. Can you provide a short, COMPLETE and self-contained example script that can be used to reproduce this? It's not much use for us to try guessing unless you don't give us the necessary information.. ------------------------------------------------------------------------ [2003-01-20 04:46:57] php@lost.co.nz Yes, you're right, the include() statement in my toy example should have been wrapped in a pair of braces - the actual code does not contain calls to include() however... I'm sorry I could not provide a backtrace - the thing refused to misbehave when gdb was listening. Prehaps someone who is more familiar with the Apache (1.3) / PHP interface will know where to examine more closely. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21756 -- Edit this bug report at http://bugs.php.net/?id=21756&edit=1