php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #34435 segmentation fault on object serialize
Submitted: 2005-09-08 23:42 UTC Modified: 2005-09-09 14:45 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: voxus at mail dot ru Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 5CVS-2005-09-09 OS: Gentoo Linux
Private report: No CVE-ID: None
View Developer Edit
 [2005-09-08 23:42 UTC] voxus at mail dot ru 
Description:
------------
php is crashing when trying to serialize any given object.  
  
problem is reproducible on x86_64 arch (known to be ok on  
x86 with any sane CFLAGS) with php-5.0.5 (5.0.4 is ok),  
for example - AMD Athlon(tm) 64 Processor 3200+.  
  
recompilation with CFLAGS="-O0" or with debug symbols 
"solves" the problem.  

Reproduce code:
---------------
compile php with CFLAGS="-O2" (yes, nothing more here)

execute from cli:

        class foo
        {
                public function bah()
                {
                        var_dump(serialize($this));
                }
        }

        $foo = new foo();
        $foo->bah();


Expected result:
----------------
var_dump'ed serialized object, i.e. - just string  

Actual result:
--------------
segmentation fault.  
  
backtrace from php: 
 
(gdb) bt 
#0  0x00000037ecf6fb9b in memcpy () from /lib/libc.so.6 
#1  0x000000000053c8ed in zif_var_export () 
#2  0x000000000053e419 in php_var_serialize () 
#3  0x000000000053e4d6 in zif_serialize () 
#4  0x00000000005c76cb in zend_do_fcall_common_helper () 
#5  0x00000000005c7941 in zend_do_fcall_handler () 
#6  0x00000000005bad54 in execute () 
#7  0x00000000005c721e in zend_do_fcall_common_helper () 
#8  0x00000000005bad54 in execute () 
#9  0x0000000000597806 in zend_execute_scripts () 
#10 0x000000000055e379 in php_execute_script () 
#11 0x00000000005d1779 in main ()

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-09 09:39 UTC] m at aptual dot fi 
I ran into this problem too, however the segmentation fault only occurs when I use 

./configure --with-apxs2=/usr/local/apache/bin/apxs

to compile PHP, instead of just ./configure. Yet the segmentation fault is not limited to the apache module, but the sapi/cli/php binary crashes as well. And just as stated by the previous poster, --enable-debug 'fixes' the problem.

I'm using Apache 2.0.52, an SMP kernel version 2.6.8 (x86_64) and gcc version 3.3.4.
 [2005-09-09 09:41 UTC] tony2001@php.net 
Try to get some more info with valgrind (since the problem is reproducible only by you).
 [2005-09-09 10:23 UTC] m at aptual dot fi 
I'm not sure if this was directed at me, but here's my 2 eurocents anyway (using the same script):

My GDB output:
http://m.bytech.fi/dev/php505gdb.txt

And with Valgrind:
http://m.bytech.fi/dev/php505valgrind.txt
 [2005-09-09 10:33 UTC] tony2001@php.net 
That's much better.
And could you plz do:
gdb> f1
after "bt" to see what exactly happens there?
 [2005-09-09 10:42 UTC] m at aptual dot fi 
(gdb) f 1
#1  0x00000000004ee11a in php_var_serialize_class_name (buf=0x7fbfffce40, struc=0x7f00000013)
    at /usr/src/php-5.0.5/ext/standard/var.c:519
519             smart_str_appendl(buf, class_name, name_len);
 [2005-09-09 10:48 UTC] tony2001@php.net 
..and now please
gdb> p buf
gdb> p classname
gdb> p name_len
?
 [2005-09-09 10:52 UTC] m at aptual dot fi 
I'm guessing you meant p class_name:

(gdb) p buf
$3 = (smart_str *) 0x7fbfffce40
(gdb) p class_name
$4 = 0x7eede8 ""
(gdb) p name_len
$5 = 545460846595
 [2005-09-09 10:57 UTC] tony2001@php.net 
Thanks.
Is it possible to get an account with minimal privileges at this server?
 [2005-09-09 11:02 UTC] m at aptual dot fi 
I'm afraid it's behind a firewall (which I can't open any ports to), and so are all of our other 64-bit machines.
 [2005-09-09 11:33 UTC] voxus at mail dot ru 
btw, what platform you're using, m?
 [2005-09-09 12:07 UTC] m at aptual dot fi 
I'm not sure what you mean exactly with platform, but like I said before, I'm using Apache 2.0.52, an SMP kernel version 2.6.8 (x86_64) and gcc version 3.3.4. The glibc6 version is 2.3.2. 

To be more precise, the machine is a Dual Opteron box, and it is running on Ubuntu Linux (Warty). However, both Apache and PHP have been compiled from sources. Oh, and Apache uses the Prefork MPM, which should be (and has been, so far) safe to use with PHP. 

And just like with the initial poster, this problem doesn't occur on, for example, PHP 5.0.3. I noticed this during a normal upgrade, when an application stopped working immediately after trying the new version.
 [2005-09-09 12:51 UTC] etnu at etnu dot org 
Experiencing the exact same problem with an identical configuration, just using Apache 2.0.54 instead of 2.0.52. 

Same hardware though; running under Debian 3.1 (Sarge)

export CFLAGS="-O2"
./configure \
--with-tidy \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql=/usr --with-mysqli=/usr/bin/mysql_config \
--prefix=/usr/local/apache2/php \
--with-config-file-path=/usr/local/apache2/php \
--enable-force-cgi-redirect \
--disable-magic-quotes \
--with-gd --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib \
--with-freetype-dir=/usr/lib --with-zlib-dir=/usr/lib

I actually get compiler warnings with this configuration:

/usr/src/php-5.0.5/ext/sqlite/libsqlite/src/func.c: In function `minmaxFunc':
/usr/src/php-5.0.5/ext/sqlite/libsqlite/src/func.c:38: warning: cast from pointer to integer of different size
/usr/src/php-5.0.5/ext/sqlite/libsqlite/src/func.c: In function `minmaxStep':
/usr/src/php-5.0.5/ext/sqlite/libsqlite/src/func.c:525: warning: cast from pointer to integer of different size
/usr/src/php-5.0.5/ext/standard/var.c: In function `php_var_serialize_class_name':
/usr/src/php-5.0.5/ext/standard/var.c:515: warning: passing arg 3 of `zend_get_object_classname' from incompatible pointer type

An identical build of 5.0.4 yields no warnings at all. I'm seeing seg faults whenever serializing or unserializing any object.
 [2005-09-09 13:36 UTC] tony2001@php.net 
Just ignore those warnings. They are just warnings and have nothing to do with the issue.
You'd better provide more info and/or access to the server where it's reproducible.
 [2005-09-09 13:38 UTC] voxus at mail dot ru 
reproducible with today's snapshot too.
 [2005-09-09 14:02 UTC] jorton@php.net 
Eh? The warning shows *precisely* why the code is broken on LP64 platforms.  Reporter, can you try this patch.

http://people.apache.org/~jorton/php_bug34435.patch
 [2005-09-09 14:26 UTC] m at aptual dot fi 
The patch posted by jorton seems to have fixed the problem I experienced, at least with this particular test case. I will do some more testing on an actual application to see if this affects anything else.
 [2005-09-09 14:45 UTC] voxus at mail dot ru 
yep, patch by jorton solves problem. 
 
thank you, guys. :-)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Dec 25 16:01:28 2024 UTC