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

go to bug id or search bugs for

Bug #67314 Segmentation fault in gc_remove_zval_from_buffer
Submitted: 2014-05-20 21:22 UTC Modified: 2014-06-24 06:14 UTC
Votes:3
Avg. Score:4.7 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: webm4st0r at gmail dot com Assigned: dmitry (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.5.12 OS: CentOS confirmed
Private report: No CVE-ID: None
View Developer Edit
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: webm4st0r at gmail dot com
New email:
PHP Version: OS:

 

 [2014-05-20 21:22 UTC] webm4st0r at gmail dot com 
Description:
------------
I have encountered a reproducible crash on PHP 5.5.0 and greater.

This is simple to work around as it just requires that you declare variables properly, but I suspect the engine should not segfault :).

This seems to require that a custom error handler be registered.

I reported a similar bug a while back that this reminds me of, but may not be related:

https://bugs.php.net/bug.php?id=66127

3v4l output:
http://3v4l.org/lespU

Test script:
---------------
<?php
function crash()
{
    $notDefined[$i] = 'test';
}

function error_handler() { return false; }

set_error_handler('error_handler');
crash();
echo "made it once\n";
crash();
echo "ok\n";

Expected result:
----------------
Notice: Undefined variable: i in /in/lespU on line 4
made it once

Notice: Undefined variable: i in /in/lespU on line 4
ok

Actual result:
--------------
Notice: Undefined variable: i in /in/lespU on line 4
made it once

Notice: Undefined variable: i in /in/lespU on line 4

Process exited with code 139.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-06-05 11:13 UTC] arjen at react dot com 
Easy to reproduce, also crashes with zend.enable_gc=0

Valgrind log:
==3277== Invalid write of size 8
==3277==    at 0x7AF480: gc_remove_zval_from_buffer (zend_gc.h:189)
==3277==    by 0x780CA7: _zval_ptr_dtor (zend_execute.h:80)
==3277==    by 0x79E427: zend_hash_clean (zend_hash.c:596)
==3277==    by 0x8444C4: zend_clean_and_cache_symbol_table (zend_execute.c:1498)
==3277==    by 0x844602: zend_leave_helper_SPEC (zend_vm_execute.h:438)
==3277==    by 0x7BA477: execute_ex (zend_vm_execute.h:363)
==3277==    by 0x79216A: zend_execute_scripts (zend.c:1316)
==3277==    by 0x7315F0: php_execute_script (main.c:2506)
==3277==    by 0x849F5B: do_cli (php_cli.c:994)
==3277==    by 0x4312E6: main (php_cli.c:1378)
==3277==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3277== 
==3277== 
==3277== Process terminating with default action of signal 11 (SIGSEGV)
==3277==  Access not within mapped region at address 0x0
==3277==    at 0x7AF480: gc_remove_zval_from_buffer (zend_gc.h:189)
==3277==    by 0x780CA7: _zval_ptr_dtor (zend_execute.h:80)
==3277==    by 0x79E427: zend_hash_clean (zend_hash.c:596)
==3277==    by 0x8444C4: zend_clean_and_cache_symbol_table (zend_execute.c:1498)
==3277==    by 0x844602: zend_leave_helper_SPEC (zend_vm_execute.h:438)
==3277==    by 0x7BA477: execute_ex (zend_vm_execute.h:363)
==3277==    by 0x79216A: zend_execute_scripts (zend.c:1316)
==3277==    by 0x7315F0: php_execute_script (main.c:2506)
==3277==    by 0x849F5B: do_cli (php_cli.c:994)
==3277==    by 0x4312E6: main (php_cli.c:1378)
==3277==  If you believe this happened as a result of a stack
==3277==  overflow in your program's main thread (unlikely but
==3277==  possible), you can try to increase the size of the
==3277==  main thread stack using the --main-stacksize= flag.
==3277==  The main thread stack size used in this run was 8388608.
==3277== 
==3277== HEAP SUMMARY:
==3277==     in use at exit: 3,398,590 bytes in 18,007 blocks
==3277==   total heap usage: 22,264 allocs, 4,257 frees, 3,620,171 bytes allocated
==3277== 
==3277== LEAK SUMMARY:
==3277==    definitely lost: 32 bytes in 1 blocks
==3277==    indirectly lost: 241 bytes in 4 blocks
==3277==      possibly lost: 0 bytes in 0 blocks
==3277==    still reachable: 3,398,317 bytes in 18,002 blocks
==3277==         suppressed: 0 bytes in 0 blocks
==3277== Rerun with --leak-check=full to see details of leaked memory
==3277== 
==3277== For counts of detected and suppressed errors, rerun with: -v
==3277== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 3)
 [2014-06-24 06:14 UTC] dmitry@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: dmitry
 [2015-04-08 18:27 UTC] dmitry@php.net 
Automatic comment on behalf of dmitry@zend.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=741c5e4c0c4d666469215d21de8a743a6b292fa2
Log: Fixed bug #67314 (Segmentation fault in gc_remove_zval_from_buffer)
 [2015-04-08 18:27 UTC] dmitry@php.net
-Status: Assigned +Status: Closed
 [2015-04-08 18:27 UTC] dmitry@php.net 
Automatic comment on behalf of dmitry@zend.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=174b9ee6347b551c1d99a41189c9d1410e6cdd47
Log: Fixed bug #67314 (Segmentation fault in gc_remove_zval_from_buffer)
 [2015-06-02 12:01 UTC] kozzi11 at gmail dot com 
I have same segfault problem on php 5.4. I guess same fix could be applied
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 11:01:29 2024 UTC