|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #29090 Destructor Segfaults PHP5RC3
Submitted: 2004-07-11 05:47 UTC Modified: 2004-07-26 06:36 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: derek at battams dot ca Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 5.0.0 OS: *
Private report: No CVE-ID: None
 [2004-07-11 05:47 UTC] derek at battams dot ca
PHP segfaults when trying to use the result of md5 or sha1 (tried md5 initally, then tried sha1 when code kept segfaulting) as a file name in my destructor.  Unfortunately, I can't reproduce the crash with a small script (the class in question is part of a much larger system), but I know how to elimite the segfault within the project's codebase.  If I remove the call to md5 in the sample code then there's no segfault (no matter how hard I try).  Once I put the md5 (or sha1) call back into the destructor then the segfault returns immediately.

Reproduce code:
   public function __destruct()
      $cacheFile1 = BP_CACHE . "/" . md5($this->getDN());
      $cacheFile2 = BP_CACHE . "/" . md5($this->findAttribute("mail"));
      if(!file_exists($cacheFile1) || !file_exists($cacheFile2) || !(is_link($cacheFile1) xor is_link($cacheFile2)))
         if(file_exists($cacheFile1) && !is_link($cacheFile1))
            @symlink(basename($cacheFile1), $cacheFile2);
         else if(file_exists($cacheFile2) && !is_link($cacheFile2))
            @symlink(basename($cacheFile2), $cacheFile1);

Expected result:
Destructor returns with no segfault.

Actual result:
(gdb) bt
#0  0x081a3c99 in zend_hash_find (ht=0x4042cc5c,
    arKey=0x4042c734 "cacheFile1", nKeyLength=11, pData=0x33303934)
    at /tmp/php-5.0.0RC3/Zend/zend_hash.c:846
#1  0x081b74b6 in zend_fetch_var_address (opline=0x404323b8, Ts=0xbfffe030,
    type=0) at /tmp/php-5.0.0RC3/Zend/zend_execute.c:762

#2  0x081b9c5f in zend_fetch_r_handler (execute_data=0xbfffe6d0,
    opline=0x404323b8, op_array=0x4042c25c)
    at /tmp/php-5.0.0RC3/Zend/zend_execute.c:1994
#3  0x081b8a77 in execute (op_array=0x4042c25c)
    at /tmp/php-5.0.0RC3/Zend/zend_execute.c:1389
#4  0x08194fa6 in zend_call_function (fci=0xbfffe850, fci_cache=0xbfffe830)
    at /tmp/php-5.0.0RC3/Zend/zend_execute_API.c:835
#5  0x081aa0c2 in zend_call_method (object_pp=0xbfffe8dc, obj_ce=0x4042b824,
    fn_proxy=0x0, function_name=0x81f9c04 "__destruct", function_name_len=10,
    retval_ptr_ptr=0x0, param_count=1078141880, arg1=0x0, arg2=0x0)
    at /tmp/php-5.0.0RC3/Zend/zend_interfaces.c:79
#6  0x081ac3e1 in zend_objects_destroy_object (object=0x4043bf54,    handle=1078141880) at /tmp/php-5.0.0RC3/Zend/zend_objects.c:78
#7  0x081ae106 in zend_objects_store_call_destructors (objects=0x82521d4)
    at /tmp/php-5.0.0RC3/Zend/zend_objects_API.c:54
#8  0x0819428c in shutdown_executor ()
    at /tmp/php-5.0.0RC3/Zend/zend_execute_API.c:209
#9  0x0819db09 in zend_deactivate () at /tmp/php-5.0.0RC3/Zend/zend.c:819
#10 0x0816cdb5 in php_request_shutdown (dummy=0x0)
    at /tmp/php-5.0.0RC3/main/main.c:1212
#11 0x081c3e8e in main (argc=2, argv=0xbffff6a4)
    at /tmp/php-5.0.0RC3/sapi/cli/php_cli.c:1046
#12 0x42015574 in __libc_start_main () from /lib/tls/

Also, this from the debug enabled PHP binary:

[dbattams@caboose public_html]$ $R/php test.person.php
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ?̏*̏*D) (source: /tmp/php-5.0.0RC3/Zend/zend_execute_API.c:391) in Unknown on line 0
[Sat Jul 10 23:41:43 2004]  Script:  'test.person.php'
/tmp/php-5.0.0RC3/Zend/zend_execute_API.c(391) : Block 0x4140E9D4
/tmp/php-5.0.0RC3/Zend/zend_variables.c(45) : Actual location (location was relayed)
Beginning:      Cached (allocated on /tmp/php-5.0.0RC3/main/streams/streams.c:1529, 69 bytes)
      End:      OK


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-07-17 19:28 UTC] derek at battams dot ca
This problem has carried over into the 5.0.0 final release.
 [2004-07-25 21:12 UTC]
Please try using this CVS snapshot:
For Windows:

 [2004-07-25 21:51 UTC] marcus at lucidix dot com
We are experiencing a similar seg fault, also in zend_hash_find. 

Two servers running Linux 2.4, Apache 1.3, MySQL 4.0, PHP 5.0 (also tested with CVS php5-200407242230.tar.bz2) segfault. 

However, our application runs without issues on Windows XP, Apache 2.0, MySQL 4.0, PHP 5.0.0.

The class this error occurs in is also part of a much larger system. We have not yet been able to isolate the exact line of code causing this. Additionally, the behavior is not consistent. Seg faults occur 95% of the time, but occasionally it will run.

A few differences to the original bug report: We are not using destructors, and no calls to md5 are made. The only common code between our two code snippets is file_exists().

Please note: The following code snippet will not work by itself.

Reproduce code:
	function _findstoredproc($storedproc)
		// load the list of modules installed
		$modmgr = lxModules::singleton();
		$modules = $modmgr->modulelist();

		// prepend the "core" module
		$core = array(
			'name' => 'core',
			'type' => 'global',
			'path' => GLOBALDIR . '/src/'

		array_unshift($modules, $core);

		// scan each module
		foreach($modules as $module)
			// assemble the file name, using module directory, drv/, proc name and driver extension
			$filename = $module['path'] . 'drv/' . $storedproc . '.' . $this->db_driver;
			// check if the "stored proc" exists
			if (file_exists($filename))
				return $filename;
		return false;

Expected Result:
Function returns a filename or false.

Actual Result:
"The page cannot be displayed" as the Apache child process seg faults.

Apache Error Log:
/usr/local/src/php5-200407242230/main/streams/streams.c(1551) : Block 0x0838E678 status:
Beginning:      Overrun (magic=0x4020F0E4, expected=0x7312F8DC)
      End:      Unknown
[Sun Jul 25 13:25:31 2004]  Script:  '/home/marcus/public_html/webapp/trunk/index.lx'
/usr/local/src/php5-200407242230/Zend/zend_constants.c(33) : Block 0x404D9CA3 status:
/usr/local/src/php5-200407242230/Zend/zend_variables.c(39) : Actual location (location was relayed)
Beginning:      Overrun (magic=0x75622E6E, expected=0x7312F8DC)
[Sun Jul 25 13:25:32 2004] [notice] child pid 18603 exit signal Segmentation fault (11)

GDB Backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14684)]
0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc "filename", nKeyLength=9,
    pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
854                     if ((p->h == h) && (p->nKeyLength == nKeyLength)) {

(gdb) bt

#0  0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc "filename", nKeyLength=9,
    pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
#1  0x4078920f in zend_fetch_var_address (opline=0x823bc38, Ts=0x833ea5c, type=0)
    at /usr/local/src/php-5.0.0/Zend/zend_execute.c:762
#2  0x4078c5ef in zend_fetch_r_handler (execute_data=0xbfffeb60, opline=0x823bc38,
    op_array=0x82b6fc4) at /usr/local/src/php-5.0.0/Zend/zend_execute.c:1996
#3  0x4078acc4 in execute (op_array=0x82b6fc4) at /usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
#4  0x4078edd5 in zend_do_fcall_common_helper (execute_data=0xbfffec50, opline=0x823e9c4,
    op_array=0x823c064) at /usr/local/src/php-5.0.0/Zend/zend_execute.c:2728
#5  0x4078f2ef in zend_do_fcall_by_name_handler (execute_data=0xbfffec50, opline=0x823e9c4,
    op_array=0x823c064) at /usr/local/src/php-5.0.0/Zend/zend_execute.c:2810
#6  0x4078acc4 in execute (op_array=0x823c064) at /usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
#7  0x4078edd5 in zend_do_fcall_common_helper (execute_data=0xbfffed40, opline=0x82655fc,
    op_array=0x8266174) at /usr/local/src/php-5.0.0/Zend/zend_execute.c:2728
#8  0x4078f2ef in zend_do_fcall_by_name_handler (execute_data=0xbfffed40, opline=0x82655fc,
    op_array=0x8266174) at /usr/local/src/php-5.0.0/Zend/zend_execute.c:2810
#9  0x4078acc4 in execute (op_array=0x8266174) at /usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
#10 0x40756674 in zend_call_function (fci=0xbfffeeb0, fci_cache=0x0)
    at /usr/local/src/php-5.0.0/Zend/zend_execute_API.c:835
#11 0x407555ac in call_user_function_ex (function_table=0x8150288, object_pp=0x0,
    function_name=0x824163c, retval_ptr_ptr=0xbfffef14, param_count=2, params=0x82305cc,
    no_separation=1, symbol_table=0x0) at /usr/local/src/php-5.0.0/Zend/zend_execute_API.c:550
#12 0x40755463 in call_user_function (function_table=0x8150288, object_pp=0x0,
    function_name=0x824163c, retval_ptr=0x833cdec, param_count=2, params=0xbfffef98)
    at /usr/local/src/php-5.0.0/Zend/zend_execute_API.c:525
#13 0x4061a59b in ps_call_handler (func=0x824163c, argc=2, argv=0xbfffef98)
    at /usr/local/src/php-5.0.0/ext/session/mod_user.c:60
#14 0x4061abcb in ps_write_user (mod_data=0x4082feb0,
    key=0x8241b2c "9541b01fe73fd7dcc43389ececda7949",
    val=0x833f3ec "theme|s:7:\"default\";navmenu|s:4770:\"var myMenu = [[' ', 'My Office', '/index.lx?_mod=transact&_file=index', '_self', 'Go to My Work"..., vallen=5243) at /usr/local/src/php-5.0.0/ext/session/mod_user.c:148
#15 0x40614d51 in php_session_save_current_state ()
    at /usr/local/src/php-5.0.0/ext/session/session.c:802
#16 0x40619049 in php_session_flush () at /usr/local/src/php-5.0.0/ext/session/session.c:1708
#17 0x40619074 in zm_deactivate_session (type=1, module_number=7)
    at /usr/local/src/php-5.0.0/ext/session/session.c:1722
#18 0x40767fa0 in module_registry_cleanup (module=0x80e3b88)
    at /usr/local/src/php-5.0.0/Zend/zend_API.c:1469
#19 0x4076c22e in zend_hash_apply (ht=0x40834380, apply_func=0x40767f5d <module_registry_cleanup>)
    at /usr/local/src/php-5.0.0/Zend/zend_hash.c:664
#20 0x40762ae5 in zend_deactivate_modules () at /usr/local/src/php-5.0.0/Zend/zend.c:804
#21 0x40715391 in php_request_shutdown (dummy=0x0) at /usr/local/src/php-5.0.0/main/main.c:1198
#22 0x40797c92 in apache_php_module_main (r=0x815c834, display_source_mode=0)
    at /usr/local/src/php-5.0.0/sapi/apache/sapi_apache.c:60
#23 0x40798c85 in send_php (r=0x815c834, display_source_mode=0,
    filename=0x815e364 "/home/marcus/public_html/webapp/trunk/index.lx")
    at /usr/local/src/php-5.0.0/sapi/apache/mod_php5.c:622
#24 0x40798d0a in send_parsed_php (r=0x815c834)
    at /usr/local/src/php-5.0.0/sapi/apache/mod_php5.c:637
#25 0x08053ab4 in ap_invoke_handler ()
#26 0x0806342c in ap_some_auth_required ()
#27 0x08063488 in ap_process_request ()
#28 0x0805cc6b in ap_child_terminate ()
#29 0x0805cdfc in ap_child_terminate ()
#30 0x0805cf19 in ap_child_terminate ()
#31 0x0805d3f5 in ap_child_terminate ()
#32 0x0805dafd in main ()
#33 0x400f4da6 in __libc_start_main () from /lib/

(gdb) frame 3
#3  0x4078acc4 in execute (op_array=0x82b6fc4) at /usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
1391                    if (EX(opline)->handler(&execute_data, EX(opline), op_array TSRMLS_CC)) {

(gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x82b6edc "_findstoredproc"

(gdb) print (char *)executor_globals.active_op_array->function_name
$2 = 0x82b6edc "_findstoredproc"

(gdb) print (char *)executor_globals.active_op_array->filename
$3 = 0x82028d4 "/data/home/marcus/public_html/webapp/trunk/gbl/src/class.backend2.lx"
 [2004-07-26 04:30 UTC] derek at battams dot ca
The snapshot build (200407260030) seems to fix this issue.  My initial tests are unable to reproduce the seg fault, but as my entire project team runs through its tests then I'll know more (though it was my code that was causing the seg fault and it's not seg faulting anymore so I'd say it definitely looks promising).

Assuming this fix is good, is it safe to assume then that it will appear in the 5.0.1 release?  I ask, because phpinfo() on the snapshot build shows 5.1.0-devel as the version.  Finally, how stable are the nightlies?  I assume we'll be going live with our system before 5.0.1 is released (middle August).
 [2004-07-26 06:36 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

The fix will be in 5.0.1 and we hope to get it out very soon.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Wed Feb 08 00:05:48 2023 UTC