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

go to bug id or search bugs for

Bug #24842 Corrupted memory/segfault when using destructors
Submitted: 2003-07-28 08:34 UTC Modified: 2003-08-04 06:57 UTC
From: vma1 at abv dot bg Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 5CVS-2003-07-28 (dev) OS: Slackware Linux 9.0
Private report: No CVE-ID: None
View Developer Edit
 [2003-07-28 08:34 UTC] vma1 at abv dot bg 
Description:
------------
This is a repost of an existing bug that was closed. Running the following script from the comman line causes memory corruption or a segfault.


Reproduce code:
---------------
<?
class database
{
}

$a = new database;
$b = new database;

class broken
{
        public function __construct ()
        {
        }

        public function __destruct ()
        {
                $this->show (array (
                        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
                        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
                        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
                        "", "", "", "", "", "", "", "", "", "", "", "", "", ""
                ));
        }

        private function show ($values)
        {
                $values_string = "";
                foreach ($values as $val) {
                        $values_string .= $val;
                }
                printf ("%s\n", $values_string);
        }
}

$brk = new broken ();
?>


Expected result:
----------------
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Actual result:
--------------
This is the gdb backtrace when a segfault happens. In other cases the output string is corrupted.

#0  0x08180134 in _zval_ptr_dtor (zval_ptr=0x402c3a48, __zend_filename=0x81ef380 "/usr/src/php5-200307280930/Zend/zend_variables.c", __zend_lineno=165)
    at /usr/src/php5-200307280930/Zend/zend_execute_API.c:352
352             (*zval_ptr)->refcount--;
(gdb) bt
#0  0x08180134 in _zval_ptr_dtor (zval_ptr=0x402c3a48, __zend_filename=0x81ef380 "/usr/src/php5-200307280930/Zend/zend_variables.c", __zend_lineno=165)
    at /usr/src/php5-200307280930/Zend/zend_execute_API.c:352
#1  0x08188f19 in _zval_ptr_dtor_wrapper (zval_ptr=0x402c3a48) at /usr/src/php5-200307280930/Zend/zend_variables.c:165
#2  0x08190145 in zend_hash_clean (ht=0x402d0d04) at /usr/src/php5-200307280930/Zend/zend_hash.c:536
#3  0x081a931a in zend_do_fcall_common_helper (execute_data=0xbfffebe0, op_array=0x402cfe20) at /usr/src/php5-200307280930/Zend/zend_execute.c:2560
#4  0x081a9595 in zend_do_fcall_by_name_handler (execute_data=0xbfffebe0, op_array=0x402cfe20) at /usr/src/php5-200307280930/Zend/zend_execute.c:2613
#5  0x081a54f2 in execute (op_array=0x402cfe20) at /usr/src/php5-200307280930/Zend/zend_execute.c:1192
#6  0x081811be in fast_call_user_function (function_table=0x402cf954, object_pp=0xbfffedb8, function_name=0x402d0b14, retval_ptr_ptr=0xbfffedb0,
    param_count=0, params=0x0, no_separation=0, symbol_table=0xbfffed80, function_pointer=0xbfffed44)
    at /usr/src/php5-200307280930/Zend/zend_execute_API.c:703
#7  0x08180792 in call_user_function_ex (function_table=0x0, object_pp=0xbfffedb8, function_name=0x402d0b14, retval_ptr_ptr=0xbfffedb0, param_count=0,
    params=0x0, no_separation=0, symbol_table=0xbfffed80) at /usr/src/php5-200307280930/Zend/zend_execute_API.c:486
#8  0x081986d9 in zend_objects_destroy_object (object=0x402d0c5c, handle=3) at /usr/src/php5-200307280930/Zend/zend_objects.c:79
#9  0x0819a724 in zend_objects_store_del_ref (zobject=0x402d0c18) at /usr/src/php5-200307280930/Zend/zend_objects_API.c:142
#10 0x08188d13 in _zval_dtor (zvalue=0x402d0c18, __zend_filename=0x81ee8a0 "/usr/src/php5-200307280930/Zend/zend_execute_API.c", __zend_lineno=354)
    at /usr/src/php5-200307280930/Zend/zend_variables.c:61
#11 0x08180159 in _zval_ptr_dtor (zval_ptr=0x402d0e0c, __zend_filename=0x81ef380 "/usr/src/php5-200307280930/Zend/zend_variables.c", __zend_lineno=165)
    at /usr/src/php5-200307280930/Zend/zend_execute_API.c:354
#12 0x08188f19 in _zval_ptr_dtor_wrapper (zval_ptr=0x402d0e0c) at /usr/src/php5-200307280930/Zend/zend_variables.c:165
#13 0x0819000c in zend_hash_destroy (ht=0x82082b0) at /usr/src/php5-200307280930/Zend/zend_hash.c:510
#14 0x0817fc01 in shutdown_executor () at /usr/src/php5-200307280930/Zend/zend_execute_API.c:211
#15 0x0818a07d in zend_deactivate () at /usr/src/php5-200307280930/Zend/zend.c:795
#16 0x081525ef in php_request_shutdown (dummy=0x0) at /usr/src/php5-200307280930/main/main.c:1174
#17 0x081b0a9d in main (argc=4, argv=0xbffffa94) at /usr/src/php5-200307280930/sapi/cgi/cgi_main.c:1617
#18 0x401a5bb4 in __libc_start_main () from /lib/libc.so.6
(gdb)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-07-28 08:53 UTC] vma1 at abv dot bg 
In this case php was compiled and installed with:
configure --enable-debug --without-pear;make;make install

the script was run with:
php -f ./bug.php
 [2003-07-29 06:06 UTC] sniper@php.net 
I'm still unable to reproduce this, can you try running
the script with this command:

# sapi/cli/php -n test.php

(to make it ignore any php.ini you have..)
 [2003-07-29 06:34 UTC] vma1 at abv dot bg 
"php -n bug.php" gives the same script output, including the segfault. The only difference are the HTTP headers in the beginning, because of the missing -f option.
I started digging into the PHP code, so I'll post a patch when/if I correct the bug.
 [2003-07-29 06:44 UTC] sniper@php.net 
Also tested with the CGI, can't reproduce this with it either. And neither could anybody else reproduce this (whom I asked). So are you sure there is a bug? And not just something wrong with your system? Which GCC are you using?
What glibc do you have?
 [2003-07-29 07:00 UTC] vma1 at abv dot bg 
root@www:~# gcc --version
gcc (GCC) 3.2.2
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@www:~# ls -la /lib/libc*
-rwxr-xr-x    1 root     root      1435624 Mar  5 05:57 /lib/libc-2.3.1.so*
lrwxrwxrwx    1 root     root           13 Jun  3 21:23 /lib/libc.so.6 -> libc-2.3.1.so*

root@www:~# ldd /usr/src/php5-200307280930/sapi/cli/php
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4001d000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4004b000)
        libm.so.6 => /lib/libm.so.6 (0x4005c000)
        libdl.so.2 => /lib/libdl.so.2 (0x4007f000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40082000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40097000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0x400a4000)
        libc.so.6 => /lib/libc.so.6 (0x40190000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

As far as I can remember everything is standard from the Slackware 9.0 distribution. The machine runs stable under heavy load so I doubt it's a hardware problem. I'll check where the problem is, anyway, cause it is critical for me.
 [2003-07-30 00:07 UTC] vma1 at abv dot bg 
I found the cause of the bug and posted a patch here:

http://marc.theaimsgroup.com/?l=php-dev&m=105954149002987&w=2
 [2003-08-04 06:57 UTC] stas@php.net 
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

commited that
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Aug 06 10:00:02 2025 UTC