This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 455592 - Apache + PHP Segmentation fault...
Apache + PHP Segmentation fault...
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: php (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Web Stack Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-16 10:06 EDT by Jóhann B. Guðmundsson
Modified: 2012-10-10 09:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-10 09:40:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gdb output from core dump (30.31 KB, text/plain)
2008-07-16 10:06 EDT, Jóhann B. Guðmundsson
no flags Details

  None (edit)
Description Jóhann B. Guðmundsson 2008-07-16 10:06:23 EDT
Description of problem:

Thought I had filed this long ago and was gonna post an update 
with proper gdb debug :)

Version-Release number of selected component (if applicable):

httpd-2.2.3-11.el5_1.3

How reproducible:


Seems to happen from time to time.

Steps to Reproduce:
1. Wait until it happens
2.
3.
  
Actual results:

Apache segmentation fault

Expected results:

No segmentation fault

Additional info:

The sky is blue.
Comment 1 Jóhann B. Guðmundsson 2008-07-16 10:06:23 EDT
Created attachment 311953 [details]
gdb output from core dump
Comment 2 Joe Orton 2008-07-16 10:48:01 EDT
Thanks for the report and stack trace!  This is most likely to be a PHP bug of
some kind; the stack trace looks like a crash at an unlikely spot, so it might
be memory corruption elsewhere.  To track this down it's probably going to be
necessary to narrow the crash down to a particular reproduction case, so:

1) keep collecting core dumps
2) work out which file is being executed in this case; in gdb, find a frame with
request_rec *r in scope then "up 13" and "print r->filename"
Comment 3 Jarkko 2008-12-20 16:02:31 EST
This could be related:

"there was a known memory corrupt issue in 5.2.5" (in practise all versions < 5.2.6)

http://www.nabble.com/Seg-faults-on-highly-trafficed-APC-site-to20886787.html#a20886787
Comment 4 Joe Orton 2009-02-04 11:41:55 EST
Have you managed to get a repro case for this or narrow it down to a particular script?   How regularly are you seeing the segfaults?    There are a couple of memory corruption fixes in Zend; we could test packages but it would be better to get a repro case first.
Comment 5 Jarkko 2009-02-23 07:50:36 EST
I'm having e.g. a really weird issue at the moment where variables change their values on-the-fly like "published" becoming "publishec" etc.

I can't really find where memory starts to corrupt, but I can tell you that rebuilding the php srpm with php version 5.2.0 makes the issue go away.

There are some Zend patches in php-5.1.6-23, but they don't fix the issue I'm having. If you know more memory corruption fixes in Zend, please consider applying them.

An upgrade to php >= 5.2 would solve most of the php related bugs here... :)
Comment 6 Joe Orton 2009-02-23 08:06:19 EST
5.2 breaks backwards compat in a few ways so we can't rebase.

Would you be willing to run test packages to verify whether the backports of the Zend fixes from upstream fix the problem you're seeing?
Comment 7 Jarkko 2009-02-23 08:22:34 EST
Yes.
Comment 8 Jarkko 2009-02-26 04:45:43 EST
This code:

echo $name."<br />";
$data = $types[$name]->convert_to_storage();
echo $name."<br />";

...would output:

published
publishec


Then... This code:

echo $name."<br />";
$data = (string)$types[$name]->convert_to_storage();
echo $name."<br />";

...would output:

published
published


I'm not sure if this helps you to find the correct memory corruption fixes from upstream, but I wanted to tell you this. It might be that in my situation PHP reuses memory address when it should allocate new memory for the return value. And when I tell PHP to cast the return value to string, then PHP allocates new memory for the return value and things work normally.

This is speculation (the code example is real but my theory is just speculation as I don't know anything about PHP internals), but I wanted to tell you this because it might fix my issue if you backport return value memory allocation/usage fixes from upstream (if there are such fixes there).

Naturally my issue might not be related to this segfault issue, but my issue is likely a bug with memory usage/allocation in Zend or something related and such bugs could cause segfaults.


Also... All memory corruption fixes are good I guess because memory corruption is always nasty (scripts break unexpectedly which might break user data also and make the user's PHP app vulnerable in terms of security) and might also make security holes I think (you might in theory be able to insert malicious code when memory gets reused).
Comment 9 Jarkko 2009-03-02 08:23:03 EST
The issue we're having seems to be happening when Zend's convert_to_string() is being called from a loop and you give it NULL.

I guess it's not that generic, but in our case, this is what we noticed.

Perhaps there are fixes upstream which touch convert_to_* and convert_to_string in particular... Although the real problem/bug could be lower / somewhere else.

Anyway, perhaps this helps.
Comment 10 Remi Collet 2012-09-26 01:42:17 EDT
As this bug report is quite old, could you please confirm is this issue still occurs ?
Comment 11 Jarkko 2012-09-26 03:03:03 EDT
We did a workaround for the Zend's convert_to_string() usage case (if value is NULL we don't call convert_to_string()). So the memory issue is not important to me anymore. I can't test it easily so it's ok like it is.

I can't say anything about this bug's actual segfault issue because I haven't seen it happening.
Comment 12 Remi Collet 2012-10-10 09:40:34 EDT
Since we have not been able to determine a reliable reproduction recipe for this issue, marking as closed

If you still face problems with this issue, please let us know.

Note You need to log in before you can comment on or make changes to this bug.