Bug 455592

Created attachment 311953 [details]
gdb output from core dump

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"

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

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.

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... :)

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?

Yes.

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).

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.

As this bug report is quite old, could you please confirm is this issue still occurs ?

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.

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.