Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455592 - Apache + PHP Segmentation fault...
Summary: Apache + PHP Segmentation fault...
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: php
Version: 5.2
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Web Stack Team
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-16 14:06 UTC by Jóhann B. Guðmundsson
Modified: 2012-10-10 13:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-10-10 13:40:34 UTC
Target Upstream Version:

Attachments (Terms of Use)
gdb output from core dump (deleted)
2008-07-16 14:06 UTC, Jóhann B. Guðmundsson
no flags Details

Description Jóhann B. Guðmundsson 2008-07-16 14:06:23 UTC
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):


How reproducible:

Seems to happen from time to time.

Steps to Reproduce:
1. Wait until it happens
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 14:06:23 UTC
Created attachment 311953 [details]
gdb output from core dump

Comment 2 Joe Orton 2008-07-16 14:48:01 UTC
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 21:02:31 UTC
This could be related:

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

Comment 4 Joe Orton 2009-02-04 16:41:55 UTC
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 12:50:36 UTC
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 13:06:19 UTC
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 13:22:34 UTC

Comment 8 Jarkko 2009-02-26 09:45:43 UTC
This code:

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

...would output:


Then... This code:

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

...would output:


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 13:23:03 UTC
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 05:42:17 UTC
As this bug report is quite old, could you please confirm is this issue still occurs ?

Comment 11 Jarkko 2012-09-26 07:03:03 UTC
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 13:40:34 UTC
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.