ID: 49098
Updated by: t...@php.net
Reported By: bugs at timj dot co dot uk
Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
To be more specific, php_mysqli_set_error gets called twice before
crashing with the same params:
Starting program: /usr/local/bin/php -c /usr/local/etc
php-bug49098.php
[Thread debugging using libthread_db enabled]
Breakpoint 1, php_mysqli_set_error (mysql_errno=0, mysql_err=0xbd1f77
"")
at /path/to/php5.2-200911070930/ext/mysqli/mysqli.c:1001
1001 {
(gdb) c
Continuing.
ok <-- *** this is program output to stdout, everything is OK here
Breakpoint 1, php_mysqli_set_error (mysql_errno=0, mysql_err=0xbd1f77
"")
at /path/to/php5.2-200911070930/ext/mysqli/mysqli.c:1001
1001 {
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
_zend_mm_alloc_int (heap=0x9e02b0, size=12)
at /path/to/php5.2-200911070930/Zend/zend_alloc.c:1785
1785 heap->cache[index] = best_fit->prev_free_block;
Previous Comments:
------------------------------------------------------------------------
[2009-11-11 23:30:33] t...@php.net
Breakpoint 1, php_mysqli_set_error (mysql_errno=0, mysql_err=0xbd1f77
"")
at /path/to/php5.2-200911070930/ext/mysqli/mysqli.c:1001
------------------------------------------------------------------------
[2009-11-11 23:14:25] ras...@php.net
Could you set a gdb breakpoint on the php_mysqli_set_error call and
show the arguments passed to it?
I still don't see anything in the code around that part that would
cause this though. It feels like something else is stepping on global
memory here, but it is too consistent to be random memory corruption.
Would be nice if someone else could reproduce it.
------------------------------------------------------------------------
[2009-11-11 23:01:13] t...@php.net
Yep. Also checked on 5.2, just in case.
Here's some valgrind from 5.3 for info:
==17517== Invalid free() / delete / delete[]
==17517== at 0x4A0633D: free (vg_replace_malloc.c:323)
==17517== by 0xABA17B9: php_mysqli_set_error (mysqli.c:1004)
==17517== by 0xABA61DD: zif_mysqli_real_connect (mysqli_api.c:1476)
==17517== by 0x656BD2: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==17517== by 0x652AFB: execute (zend_vm_execute.h:92)
==17517== by 0x656545: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==17517== by 0x652AFB: execute (zend_vm_execute.h:92)
==17517== by 0x656545: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==17517== by 0x652AFB: execute (zend_vm_execute.h:92)
==17517== by 0x656545: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==17517== by 0x652AFB: execute (zend_vm_execute.h:92)
==17517== by 0x656545: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==17517== Address 0xba0af20 is 0 bytes inside a block of size 1
free'd
==17517== at 0x4A0633D: free (vg_replace_malloc.c:323)
==17517== by 0xABA1348: zm_deactivate_mysqli (mysqli.c:711)
==17517== by 0x63165B: module_registry_cleanup (zend_API.c:1976)
==17517== by 0x63A3B3: zend_hash_reverse_apply (zend_hash.c:755)
==17517== by 0x6301EC: zend_deactivate_modules (zend.c:838)
==17517== by 0x5ED964: php_request_shutdown (main.c:1475)
==17517== by 0x6A065B: main (php_cli.c:1343)
==17517==
------------------------------------------------------------------------
[2009-11-11 22:50:47] j...@php.net
What's the valgrind output then, same as before?
------------------------------------------------------------------------
[2009-11-11 22:48:14] t...@php.net
Reverting the change from r281844 doesn't seem to fix it (tested on
5.3-snap200911111930)
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49098
--
Edit this bug report at http://bugs.php.net/?id=49098&edit=1
