ID:               21756
 User updated by:  [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-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] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

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

Reply via email to