php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #29054 throw exception causes segfault
Submitted: 2004-07-07 23:19 UTC Modified: 2004-10-10 01:00 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: auslander at tampabay dot rr dot com Assigned: andi (profile)
Status: No Feedback Package: Reproducible crash
PHP Version: 5.0.0RC3 OS: Linux 2.6.5
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: auslander at tampabay dot rr dot com
New email:
PHP Version: OS:

 

 [2004-07-07 23:19 UTC] auslander at tampabay dot rr dot com
Description:
------------
throwing an exception causes a segfault.

test case 1:
created an object (A) within another object (B).  B calls $this->A->close() then sets $this->A = null which calls $this->A->__destruct() method which calls A->close() again.  on the second call of A->close(), an exception is thrown which results in a segfault.

test case 2:
when creating A directly, without going through another object, no segfault happens, but still, no exception is thrown and no error.


Reproduce code:
---------------
http://gub.no-ip.org:8546/~auslander/bugtest.php.txt


Expected result:
----------------
expect no segfault and expect exception to be thrown/caught in both test cases.

Actual result:
--------------
test case 1 output/backtrace
---------------------------------
test 1
------
creating Bar object
Bar::__construct() called
Foo::__construct() called
closing Bar
Bar::close() called
Foo::close() called
Foo::__destruct() called
Foo::close() called
supposed to throw an exception here
Segmentation fault

#0  0x00000000 in ?? ()
#1  0x082039e3 in execute (op_array=0xf709f444)
    at /usr/local/src/php-5.0.0RC3/Zend/zend_execute.c:1389
#2  0x08206a75 in zend_do_fcall_common_helper (execute_data=0xfeeb09d0,
    opline=0xf70a1340, op_array=0xf7096304)
    at /usr/local/src/php-5.0.0RC3/Zend/zend_execute.c:2726
#3  0x08206d4c in zend_do_fcall_by_name_handler (execute_data=0xf70a08c8,
    opline=0xf70a1340, op_array=0xf7096304)
    at /usr/local/src/php-5.0.0RC3/Zend/zend_execute.c:2808
#4  0x082039e3 in execute (op_array=0xf7096304)
    at /usr/local/src/php-5.0.0RC3/Zend/zend_execute.c:1389
#5  0x081e9285 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /usr/local/src/php-5.0.0RC3/Zend/zend.c:1061
#6  0x081b753e in php_execute_script (primary_file=0xfeeb2db0)
    at /usr/local/src/php-5.0.0RC3/main/main.c:1627
#7  0x0820e112 in main (argc=3, argv=0xfeeb2e74)
    at /usr/local/src/php-5.0.0RC3/sapi/cli/php_cli.c:943

test case 2 output (no segfault/backtrace)
---------------------------------
test 2
------
creating Foo object
Foo::__construct() called
closing Foo
Foo::close() called
setting Foo to null
Foo::__destruct() called
Foo::close() called
supposed to throw an exception here


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-07-08 09:01 UTC] derick@php.net
Confirmed here, assigning to Andi.

valgrind says:
==25868==
==25868== Jump to the invalid address stated on the next line
==25868==    at 0x2A8FCC84: ???
==25868==    by 0x8313A25: zend_do_fcall_common_helper (zend_execute.c:2728)
==25868==    by 0x8313EA6: zend_do_fcall_by_name_handler (zend_execute.c:2810)
==25868==    by 0x831029E: execute (zend_execute.c:1391)
==25868==  Address 0x2A8FCC84 is not stack'd, malloc'd or free'd
==25868==

gdb says:
0x2a8fcc84 in ?? ()
(gdb) bt
#0  0x2a8fcc84 in ?? ()
#1  0x0831029f in execute (op_array=0x404e95a0)
    at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:1391
#2  0x08313a26 in zend_do_fcall_common_helper (execute_data=0xbfffd520,
    opline=0x404ec6e4, op_array=0x404e68cc)
    at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:2728
#3  0x08313ea7 in zend_do_fcall_by_name_handler (execute_data=0xbfffd520,
    opline=0x404ec6e4, op_array=0x404e68cc)
    at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:2810
#4  0x0831029f in execute (op_array=0x404e68cc)
    at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:1391
#5  0x082ec861 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /dat/dev/php/php-5.0dev/Zend/zend.c:1058
#6  0x082a6b83 in php_execute_script (primary_file=0xbffff960)
    at /dat/dev/php/php-5.0dev/main/main.c:1630
#7  0x0831cd96 in main (argc=3, argv=0xbffffa04)
    at /dat/dev/php/php-5.0dev/sapi/cli/php_cli.c:943

 [2004-07-26 18:57 UTC] not at valid dot boop
Should PHP5 have even been released without this being fixed first?!

Seems like any half-complex project (like mine) is going to choke on this commonly case.

If you could add a comment with a likely fix-by date that'd be great.
 [2004-10-02 21:28 UTC] pollita@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip

It's working with PHP_5_0 and HEAD...
 [2004-10-10 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Tue Jul 15 02:01:33 2025 UTC