Bug #49098 [Csd]: Using custom session handler causes segfault in session_save_state
Edit report at http://bugs.php.net/bug.php?id=49098edit=1
ID: 49098
Updated by: t...@php.net
Reported by:bugs at timj dot co dot uk
Summary:Using custom session handler causes segfault in
session_save_state
Status: Closed
Type: Bug
Package:Session related
Operating System: Linux
PHP Version:5.2.10
Assigned To:timj
Block user comment: N
New Comment:
This particular bug was definitely fixed in PHP 5.2.12. If you think you
can reproduce it in the latest release of PHP, I would suggest opening a
new bug with full details.
Previous Comments:
[2010-10-25 00:07:19] nn at tronix dot pl
I think the BUG still exists.
I have custom session handler based on PostgreSQL queries.
Any version above 5.2.9 segfaults immediately after I open the
application in the browser.
As soon as custom session handler is disabled - everything is working
fine.
I think that mb_string is important here, not mssql.
Brgs
Norbert
[2009-11-12 17:48:36] s...@php.net
Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revisionrevision=290608
Log: Merge 290570 (Fix bug #49098). (Rasmus)
[2009-11-12 08:20:57] s...@php.net
Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revisionrevision=290573
Log: Fix for bug #49098
[2009-11-12 07:16:03] t...@php.net
Confirmed works for me. Below tested on PHP 5.2 which also seems to work
- could you fix it on that branch too?:
--- ext/mysqli/mysqli.c.orig2009-07-17 13:17:25.0 +0100
+++ ext/mysqli/mysqli.c 2009-11-12 07:10:19.054055576 +
@@ -1003,7 +1003,11 @@
if (MyG(error_msg)) {
efree(MyG(error_msg));
}
- MyG(error_msg) = estrdup(mysql_err);
+ if(mysql_err *mysql_err) {
+ MyG(error_msg) = estrdup(mysql_err);
+ } else {
+ MyG(error_msg) = NULL;
+ }
}
/* }}} */
Many thanks Rasmus (and to Jani/Sriram for your help).
[2009-11-12 01:10:33] ras...@php.net
Should be fixed now in svn. Please verify.
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/bug.php?id=49098
--
Edit this bug report at http://bugs.php.net/bug.php?id=49098edit=1
#49098 [Fbk-Opn]: Using custom session handler causes segfault in session_save_state
ID: 49098 Updated by: t...@php.net Reported By: bugs at timj dot co dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux PHP Version: 5.2.10 New Comment: Yes it still segfaults in the same way in 5.3-snap20091930. Essentially the same valgrind output. Going back to the original issue, it started happening in 5.2.10. A diff of the mysqli directory between 5.2.9 and 5.2.10 shows only one change: mysqli_api.c in SVN r281844. Previous Comments: [2009-11-11 08:48:02] j...@php.net To narrow this down a bit: Does it happen with latest PHP 5.3 snapshot? [2009-11-10 23:35:57] ras...@php.net Looks like an ext/mysqli problem, but I looked through the code and I don't see a case where MyG(error_msg) is free'ed without being NULL'ed or immediately re-allocated. It isn't NULL'ed in the RSHUTDOWN, but it is NULL'ed in the RINIT, so there should be no way to get to php_mysqli_set_error() without it being either NULL or correctly allocated. [2009-11-10 23:11:11] t...@php.net ==23150== Invalid free() / delete / delete[] ==23150==at 0x4A0633D: free (vg_replace_malloc.c:323) ==23150==by 0xABA17B9: php_mysqli_set_error (mysqli.c:1004) ==23150==by 0xABA61DD: zif_mysqli_real_connect (mysqli_api.c:1476) ==23150==by 0x656BD2: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150== Address 0xba0af20 is 0 bytes inside a block of size 1 free'd ==23150==at 0x4A0633D: free (vg_replace_malloc.c:323) ==23150==by 0xABA1348: zm_deactivate_mysqli (mysqli.c:711) ==23150==by 0x63165B: module_registry_cleanup (zend_API.c:1976) ==23150==by 0x63A3B3: zend_hash_reverse_apply (zend_hash.c:755) ==23150==by 0x6301EC: zend_deactivate_modules (zend.c:838) ==23150==by 0x5ED964: php_request_shutdown (main.c:1475) ==23150==by 0x6A065B: main (php_cli.c:1343) ==23150== ==23150== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 2) ==23150== malloc/free: in use at exit: 753 bytes in 4 blocks. ==23150== malloc/free: 52,204 allocs, 52,201 frees, 11,636,702 bytes allocated. ==23150== For counts of detected errors, rerun with: -v ==23150== searching for pointers to 4 not-freed blocks. ==23150== checked 746,032 bytes. ==23150== ==23150== ==23150== 1 bytes in 1 blocks are definitely lost in loss record 1 of 4 ==23150==at 0x4A0763E: malloc (vg_replace_malloc.c:207) ==23150==by 0x616129: _estrdup (zend_alloc.c:2428) ==23150==by 0xABA17C1: ??? ==23150==by 0xABA61DD: ??? ==23150==by 0x656BD2: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150== ==23150== LEAK SUMMARY: ==23150==definitely lost: 1 bytes in 1 blocks. ==23150== possibly lost: 0 bytes in 0 blocks. ==23150==still reachable: 752 bytes in 3 blocks. ==23150== suppressed: 0 bytes in 0 blocks. ==23150== Reachable blocks (those to which a pointer was found) are not shown. ==23150== To see them, rerun with: --leak-check=full --show-reachable=yes [2009-11-09 17:22:26] j...@php.net Try with valgrind: # USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cli/php yourscript.php [2009-11-08 23:08:37] t...@php.net Compiling with -O0 and *without* --enable-debug gives a backtrace which is almost (not quite) the same: #0 0x006bec94 in _zend_mm_free_int () #1 0x006bfb06 in _efree () #2 0x006546cf in php_version_compare () #3 0x0065474f in zif_version_compare () #4 0x0070a98a in zend_do_fcall_common_helper_SPEC () #5 0x0070e932
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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: Reverting the change from r281844 doesn't seem to fix it (tested on 5.3-snap20091930) Previous Comments: [2009-11-11 20:41:46] t...@php.net Yes it still segfaults in the same way in 5.3-snap20091930. Essentially the same valgrind output. Going back to the original issue, it started happening in 5.2.10. A diff of the mysqli directory between 5.2.9 and 5.2.10 shows only one change: mysqli_api.c in SVN r281844. [2009-11-11 08:48:02] j...@php.net To narrow this down a bit: Does it happen with latest PHP 5.3 snapshot? [2009-11-10 23:35:57] ras...@php.net Looks like an ext/mysqli problem, but I looked through the code and I don't see a case where MyG(error_msg) is free'ed without being NULL'ed or immediately re-allocated. It isn't NULL'ed in the RSHUTDOWN, but it is NULL'ed in the RINIT, so there should be no way to get to php_mysqli_set_error() without it being either NULL or correctly allocated. [2009-11-10 23:11:11] t...@php.net ==23150== Invalid free() / delete / delete[] ==23150==at 0x4A0633D: free (vg_replace_malloc.c:323) ==23150==by 0xABA17B9: php_mysqli_set_error (mysqli.c:1004) ==23150==by 0xABA61DD: zif_mysqli_real_connect (mysqli_api.c:1476) ==23150==by 0x656BD2: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150== Address 0xba0af20 is 0 bytes inside a block of size 1 free'd ==23150==at 0x4A0633D: free (vg_replace_malloc.c:323) ==23150==by 0xABA1348: zm_deactivate_mysqli (mysqli.c:711) ==23150==by 0x63165B: module_registry_cleanup (zend_API.c:1976) ==23150==by 0x63A3B3: zend_hash_reverse_apply (zend_hash.c:755) ==23150==by 0x6301EC: zend_deactivate_modules (zend.c:838) ==23150==by 0x5ED964: php_request_shutdown (main.c:1475) ==23150==by 0x6A065B: main (php_cli.c:1343) ==23150== ==23150== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 2) ==23150== malloc/free: in use at exit: 753 bytes in 4 blocks. ==23150== malloc/free: 52,204 allocs, 52,201 frees, 11,636,702 bytes allocated. ==23150== For counts of detected errors, rerun with: -v ==23150== searching for pointers to 4 not-freed blocks. ==23150== checked 746,032 bytes. ==23150== ==23150== ==23150== 1 bytes in 1 blocks are definitely lost in loss record 1 of 4 ==23150==at 0x4A0763E: malloc (vg_replace_malloc.c:207) ==23150==by 0x616129: _estrdup (zend_alloc.c:2428) ==23150==by 0xABA17C1: ??? ==23150==by 0xABA61DD: ??? ==23150==by 0x656BD2: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150== ==23150== LEAK SUMMARY: ==23150==definitely lost: 1 bytes in 1 blocks. ==23150== possibly lost: 0 bytes in 0 blocks. ==23150==still reachable: 752 bytes in 3 blocks. ==23150== suppressed: 0 bytes in 0 blocks. ==23150== Reachable blocks (those to which a pointer was found) are not shown. ==23150== To see them, rerun with: --leak-check=full --show-reachable=yes [2009-11-09 17:22:26] j...@php.net Try with valgrind: # USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cli/php yourscript.php 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=49098edit=1
#49098 [Fbk-Opn]: Using custom session handler causes segfault in session_save_state
ID: 49098 Updated by: t...@php.net Reported By: bugs at timj dot co dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux PHP Version: 5.2.10 New Comment: 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== Previous Comments: [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-snap20091930) [2009-11-11 20:41:46] t...@php.net Yes it still segfaults in the same way in 5.3-snap20091930. Essentially the same valgrind output. Going back to the original issue, it started happening in 5.2.10. A diff of the mysqli directory between 5.2.9 and 5.2.10 shows only one change: mysqli_api.c in SVN r281844. [2009-11-11 08:48:02] j...@php.net To narrow this down a bit: Does it happen with latest PHP 5.3 snapshot? [2009-11-10 23:35:57] ras...@php.net Looks like an ext/mysqli problem, but I looked through the code and I don't see a case where MyG(error_msg) is free'ed without being NULL'ed or immediately re-allocated. It isn't NULL'ed in the RSHUTDOWN, but it is NULL'ed in the RINIT, so there should be no way to get to php_mysqli_set_error() without it being either NULL or correctly allocated. 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=49098edit=1
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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: Breakpoint 1, php_mysqli_set_error (mysql_errno=0, mysql_err=0xbd1f77 ) at /path/to/php5.2-200911070930/ext/mysqli/mysqli.c:1001 Previous Comments: [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-snap20091930) [2009-11-11 20:41:46] t...@php.net Yes it still segfaults in the same way in 5.3-snap20091930. Essentially the same valgrind output. Going back to the original issue, it started happening in 5.2.10. A diff of the mysqli directory between 5.2.9 and 5.2.10 shows only one change: mysqli_api.c in SVN r281844. 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=49098edit=1
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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
1785heap-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-snap20091930)
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=49098edit=1
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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:
Nope, still the same result. (back on the 5.3 snapshot now)
Previous Comments:
[2009-11-11 23:38:53] ras...@php.net
Could you try this patch and see if it changes anything?
Index: mysqli_nonapi.c
===
--- mysqli_nonapi.c (revision 290565)
+++ mysqli_nonapi.c (working copy)
@@ -46,7 +46,11 @@
if (MyG(error_msg)) {
efree(MyG(error_msg));
}
- MyG(error_msg) = estrdup(mysql_err);
+ if(mysql_err) {
+ MyG(error_msg) = estrdup(mysql_err);
+ } else {
+ MyG(error_msg) = NULL;
+ }
}
/* }}} */
[2009-11-11 23:38:36] t...@php.net
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
1785heap-cache[index] = best_fit-prev_free_block;
[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==
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=49098edit=1
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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:
Stepping through the code though, that patch wouldn't have made any
difference. On the final incantation of php_mysqli_set_error before
crash, estrdup() still gets called:
Breakpoint 1, php_mysqli_set_error (mysql_errno=0, mysql_err=0x10325a7
) at /path/to/php5.3-20091930/ext/mysqli/mysqli_nonapi.c:44
44 {
(gdb) step
45 MyG(error_no) = mysql_errno;
(gdb) step
44 {
(gdb) step
45 MyG(error_no) = mysql_errno;
(gdb) step
46 if (MyG(error_msg)) {
(gdb) step
47 efree(MyG(error_msg));
(gdb) next
49 if(mysql_err) {
(gdb) step
50 MyG(error_msg) = estrdup(mysql_err);
Previous Comments:
[2009-11-11 23:48:50] t...@php.net
Nope, still the same result. (back on the 5.3 snapshot now)
[2009-11-11 23:38:53] ras...@php.net
Could you try this patch and see if it changes anything?
Index: mysqli_nonapi.c
===
--- mysqli_nonapi.c (revision 290565)
+++ mysqli_nonapi.c (working copy)
@@ -46,7 +46,11 @@
if (MyG(error_msg)) {
efree(MyG(error_msg));
}
- MyG(error_msg) = estrdup(mysql_err);
+ if(mysql_err) {
+ MyG(error_msg) = estrdup(mysql_err);
+ } else {
+ MyG(error_msg) = NULL;
+ }
}
/* }}} */
[2009-11-11 23:38:36] t...@php.net
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
1785heap-cache[index] = best_fit-prev_free_block;
[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.
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=49098edit=1
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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:
I'm not sure if this is useful/correct, but at first pass this stops
the crash:
--- ext/mysqli/mysqli_nonapi.c.orig 2009-10-15 23:34:41.0
+0100
+++ ext/mysqli/mysqli_nonapi.c 2009-11-11 23:56:40.271496635 +
@@ -46,7 +46,11 @@
if (MyG(error_msg)) {
efree(MyG(error_msg));
}
- MyG(error_msg) = estrdup(mysql_err);
+ if(mysql_errno!=0) {
+ MyG(error_msg) = estrdup(mysql_err);
+ } else {
+ MyG(error_msg) = NULL;
+ }
}
/* }}} */
Previous Comments:
[2009-11-11 23:55:09] t...@php.net
Stepping through the code though, that patch wouldn't have made any
difference. On the final incantation of php_mysqli_set_error before
crash, estrdup() still gets called:
Breakpoint 1, php_mysqli_set_error (mysql_errno=0, mysql_err=0x10325a7
) at /path/to/php5.3-20091930/ext/mysqli/mysqli_nonapi.c:44
44 {
(gdb) step
45 MyG(error_no) = mysql_errno;
(gdb) step
44 {
(gdb) step
45 MyG(error_no) = mysql_errno;
(gdb) step
46 if (MyG(error_msg)) {
(gdb) step
47 efree(MyG(error_msg));
(gdb) next
49 if(mysql_err) {
(gdb) step
50 MyG(error_msg) = estrdup(mysql_err);
[2009-11-11 23:48:50] t...@php.net
Nope, still the same result. (back on the 5.3 snapshot now)
[2009-11-11 23:38:53] ras...@php.net
Could you try this patch and see if it changes anything?
Index: mysqli_nonapi.c
===
--- mysqli_nonapi.c (revision 290565)
+++ mysqli_nonapi.c (working copy)
@@ -46,7 +46,11 @@
if (MyG(error_msg)) {
efree(MyG(error_msg));
}
- MyG(error_msg) = estrdup(mysql_err);
+ if(mysql_err) {
+ MyG(error_msg) = estrdup(mysql_err);
+ } else {
+ MyG(error_msg) = NULL;
+ }
}
/* }}} */
[2009-11-11 23:38:36] t...@php.net
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
1785heap-cache[index] = best_fit-prev_free_block;
[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
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=49098edit=1
#49098 [Csd]: Using custom session handler causes segfault in session_save_state
ID: 49098
Updated by: t...@php.net
Reported By: bugs at timj dot co dot uk
Status: Closed
Bug Type: Session related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
Confirmed works for me. Below tested on PHP 5.2 which also seems to
work - could you fix it on that branch too?:
--- ext/mysqli/mysqli.c.orig2009-07-17 13:17:25.0 +0100
+++ ext/mysqli/mysqli.c 2009-11-12 07:10:19.054055576 +
@@ -1003,7 +1003,11 @@
if (MyG(error_msg)) {
efree(MyG(error_msg));
}
- MyG(error_msg) = estrdup(mysql_err);
+ if(mysql_err *mysql_err) {
+ MyG(error_msg) = estrdup(mysql_err);
+ } else {
+ MyG(error_msg) = NULL;
+ }
}
/* }}} */
Many thanks Rasmus (and to Jani/Sriram for your help).
Previous Comments:
[2009-11-12 01:10:33] ras...@php.net
Should be fixed now in svn. Please verify.
[2009-11-12 01:09:16] s...@php.net
Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revisionrevision=290570
Log: Fix bug #49098
[2009-11-11 23:59:51] t...@php.net
I'm not sure if this is useful/correct, but at first pass this stops
the crash:
--- ext/mysqli/mysqli_nonapi.c.orig 2009-10-15 23:34:41.0
+0100
+++ ext/mysqli/mysqli_nonapi.c 2009-11-11 23:56:40.271496635 +
@@ -46,7 +46,11 @@
if (MyG(error_msg)) {
efree(MyG(error_msg));
}
- MyG(error_msg) = estrdup(mysql_err);
+ if(mysql_errno!=0) {
+ MyG(error_msg) = estrdup(mysql_err);
+ } else {
+ MyG(error_msg) = NULL;
+ }
}
/* }}} */
[2009-11-11 23:55:09] t...@php.net
Stepping through the code though, that patch wouldn't have made any
difference. On the final incantation of php_mysqli_set_error before
crash, estrdup() still gets called:
Breakpoint 1, php_mysqli_set_error (mysql_errno=0, mysql_err=0x10325a7
) at /path/to/php5.3-20091930/ext/mysqli/mysqli_nonapi.c:44
44 {
(gdb) step
45 MyG(error_no) = mysql_errno;
(gdb) step
44 {
(gdb) step
45 MyG(error_no) = mysql_errno;
(gdb) step
46 if (MyG(error_msg)) {
(gdb) step
47 efree(MyG(error_msg));
(gdb) next
49 if(mysql_err) {
(gdb) step
50 MyG(error_msg) = estrdup(mysql_err);
[2009-11-11 23:48:50] t...@php.net
Nope, still the same result. (back on the 5.3 snapshot now)
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=49098edit=1
#49098 [Fbk-Opn]: Using custom session handler causes segfault in session_save_state
ID: 49098 Updated by: t...@php.net Reported By: bugs at timj dot co dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux PHP Version: 5.2.10 New Comment: ==23150== Invalid free() / delete / delete[] ==23150==at 0x4A0633D: free (vg_replace_malloc.c:323) ==23150==by 0xABA17B9: php_mysqli_set_error (mysqli.c:1004) ==23150==by 0xABA61DD: zif_mysqli_real_connect (mysqli_api.c:1476) ==23150==by 0x656BD2: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150== Address 0xba0af20 is 0 bytes inside a block of size 1 free'd ==23150==at 0x4A0633D: free (vg_replace_malloc.c:323) ==23150==by 0xABA1348: zm_deactivate_mysqli (mysqli.c:711) ==23150==by 0x63165B: module_registry_cleanup (zend_API.c:1976) ==23150==by 0x63A3B3: zend_hash_reverse_apply (zend_hash.c:755) ==23150==by 0x6301EC: zend_deactivate_modules (zend.c:838) ==23150==by 0x5ED964: php_request_shutdown (main.c:1475) ==23150==by 0x6A065B: main (php_cli.c:1343) ==23150== ==23150== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 2) ==23150== malloc/free: in use at exit: 753 bytes in 4 blocks. ==23150== malloc/free: 52,204 allocs, 52,201 frees, 11,636,702 bytes allocated. ==23150== For counts of detected errors, rerun with: -v ==23150== searching for pointers to 4 not-freed blocks. ==23150== checked 746,032 bytes. ==23150== ==23150== ==23150== 1 bytes in 1 blocks are definitely lost in loss record 1 of 4 ==23150==at 0x4A0763E: malloc (vg_replace_malloc.c:207) ==23150==by 0x616129: _estrdup (zend_alloc.c:2428) ==23150==by 0xABA17C1: ??? ==23150==by 0xABA61DD: ??? ==23150==by 0x656BD2: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150==by 0x656545: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==23150==by 0x652AFB: execute (zend_vm_execute.h:92) ==23150== ==23150== LEAK SUMMARY: ==23150==definitely lost: 1 bytes in 1 blocks. ==23150== possibly lost: 0 bytes in 0 blocks. ==23150==still reachable: 752 bytes in 3 blocks. ==23150== suppressed: 0 bytes in 0 blocks. ==23150== Reachable blocks (those to which a pointer was found) are not shown. ==23150== To see them, rerun with: --leak-check=full --show-reachable=yes Previous Comments: [2009-11-09 17:22:26] j...@php.net Try with valgrind: # USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cli/php yourscript.php [2009-11-08 23:08:37] t...@php.net Compiling with -O0 and *without* --enable-debug gives a backtrace which is almost (not quite) the same: #0 0x006bec94 in _zend_mm_free_int () #1 0x006bfb06 in _efree () #2 0x006546cf in php_version_compare () #3 0x0065474f in zif_version_compare () #4 0x0070a98a in zend_do_fcall_common_helper_SPEC () #5 0x0070e932 in ZEND_DO_FCALL_SPEC_CONST_HANDLER () #6 0x0070a480 in execute () #7 0x0070ab3b in zend_do_fcall_common_helper_SPEC () #8 0x0070b081 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #9 0x0070a480 in execute () #10 0x0070ab3b in zend_do_fcall_common_helper_SPEC () #11 0x0070b081 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #12 0x0070a480 in execute () #13 0x0070ab3b in zend_do_fcall_common_helper_SPEC () #14 0x0070b081 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #15 0x0070a480 in execute () #16 0x0070ab3b in zend_do_fcall_common_helper_SPEC () #17 0x0070b081 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #18 0x0070a480 in execute () #19 0x006d2340 in zend_call_function () #20 0x006d0651 in call_user_function_ex () #21 0x006d052c in call_user_function () #22 0x005718c9 in ps_call_handler () #23 0x00571d8c in ps_write_user () #24 0x0056ab00 in php_session_save_current_state () #25 0x0056e184
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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: After spending an enormous amount of time testing endless combinations of compile and runtime options, I have hopefully found the key to solving this obscure bug. The segfault only happens specifically if the following is true: - the mbstring extension is enabled, *AND* - the mssql extension is enabled (particularly weird because the test script does not use mssql in any way) In the hope of making the reproduction scenario more robust, I have pared down the configure line to a minimum and here is the exact environment, from source tarball, which I can reproduce it in: OS: Fedora 11 x86_64 (fully updated as at 2009-11-08) Notable dependencies: mysql-devel-5.1.37-1.fc11.x86_64 freetds-devel-0.82-5.fc11.x86_64 gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) Download snapshot 200911070930 from snaps.php.net tar -jxf php5.2-200911070930.tar.bz2 cd php5.2-200911070930 ./configure --includedir=/usr/include --libdir=/usr/lib64 --with-libdir=lib64 --without-pear --with-mysqli=shared,/usr/bin/mysql_config --enable-mbstring=shared --enable-mbregex --with-mssql=shared,/usr make -j3 make install # as root create /usr/local/etc/php.ini containing only the following: extension=mbstring.so extension=mssql.so extension=mysqli.so include_path=/path/to/pear/php $ /usr/local/bin/php -c /usr/local/etc/php.ini php-bug49098.php # script posted on 11 Aug Segmentation fault Commenting out EITHER extension=mbstring.so or extension=mssql.so in /usr/local/etc/php.ini stops the segfault. Can anyone else now reproduce this with the above environment? Is there any other information about the environment that I need to provide? Previous Comments: [2009-09-26 10:54:13] t...@php.net 1. Still segfaults for me with the release version of 5.2.11, with MySQLi connection (mysql client libs and server 5.1.37). - Sriram, I also tried with your test script (just to make sure there wasn't a subtle difference from mine) and it also segfaulted. - Segfault is still in the same place as originally. 2. snap-200909261030 doesn't build atm (error in mysqli_api) What more info can I give to assist? [2009-09-24 19:32:19] srina...@php.net unable to reproduce with the earlier provided test case. so, need more information to reproduce / investigate this bug . also, would be useful to know if this still happens with either 5.2.11 (or latest svn snapshot) [2009-09-24 17:48:47] srina...@php.net i do have a wordpress running with php 5.2.11 for my site and i don't have any issues. if you do notice with the latest php build, if you can provide a test case to reproduce this bug that would be useful. as i noted earlier, i was not able to reproduce this bug with the provided test case here. [2009-09-18 19:43:06] ulf at ladb dot unm dot edu Hi, Is this bug still under investigation? Just wondering because 5.2.9 is the last version of PHP that works with Wordpress/MySQL without crashing Apache. Thanks. [2009-09-16 18:19:08] sriram dot natarajan at gmail dot com i just took the latest php snapshot from http://snaps.php.net and tried it out. if you notice, my script is just a completion of your script - i just filled in some missing pieces in your script - like creating the table etc . i am also using mysql 5.1.30 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=49098edit=1
#49098 [Fbk]: Using custom session handler causes segfault in session_save_state
ID: 49098 Updated by: t...@php.net Reported By: bugs at timj dot co dot uk Status: Feedback Bug Type: Session related Operating System: Linux PHP Version: 5.2.10 New Comment: With my original compile as per instructions above (the compiler got -O2 by default): #0 _zend_mm_alloc_int (heap=0x9e32b0, size=12) at /path/to/php5.2-200911070930/Zend/zend_alloc.c:1785 #1 0x0048227e in php_pcre_match_impl (pce=value optimized out, subject=value optimized out, subject_len=value optimized out, return_value=value optimized out, subpats=0x0, global=0, use_flags=0, flags=value optimized out, start_offset=0) at /path/to/php5.2-200911070930/ext/pcre/php_pcre.c:603 #2 0x00482ccd in php_do_pcre_match (ht=2, return_value=0xd584a0, return_value_ptr=value optimized out, this_ptr=value optimized out, return_value_used=value optimized out, global=0) at /path/to/php5.2-200911070930/ext/pcre/php_pcre.c:513 #3 0x00659303 in zend_do_fcall_common_helper_SPEC ( execute_data=0x7fffc420) at /path/to/php5.2-200911070930/Zend/zend_vm_execute.h:200 #4 0x0065522c in execute (op_array=0xd83190) at /path/to/php5.2-200911070930/Zend/zend_vm_execute.h:92 #5 0x00658c76 in zend_do_fcall_common_helper_SPEC ( execute_data=0x7fffc740) at /path/to/php5.2-200911070930/Zend/zend_vm_execute.h:234 #6 0x0065522c in execute (op_array=0xd37808) at /path/to/php5.2-200911070930/Zend/zend_vm_execute.h:92 #7 0x00658c76 in zend_do_fcall_common_helper_SPEC ( execute_data=0x7fffd660) Previous Comments: [2009-11-08 21:11:07] srina...@php.net thanks for taking time and trying to reproduce this issue. can u kindly provide / attach stack trace when this issue happens... this would help us identify us as to what is happening at ur end.. u can enable core dump by doing some thing like ulimit -c unlimited now, u can run your program to generate core dump and provide us the stack trace as mentioned in this below link.. http://bugs.php.net/bugs-generating-backtrace.php [2009-11-08 19:10:35] t...@php.net After spending an enormous amount of time testing endless combinations of compile and runtime options, I have hopefully found the key to solving this obscure bug. The segfault only happens specifically if the following is true: - the mbstring extension is enabled, *AND* - the mssql extension is enabled (particularly weird because the test script does not use mssql in any way) In the hope of making the reproduction scenario more robust, I have pared down the configure line to a minimum and here is the exact environment, from source tarball, which I can reproduce it in: OS: Fedora 11 x86_64 (fully updated as at 2009-11-08) Notable dependencies: mysql-devel-5.1.37-1.fc11.x86_64 freetds-devel-0.82-5.fc11.x86_64 gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) Download snapshot 200911070930 from snaps.php.net tar -jxf php5.2-200911070930.tar.bz2 cd php5.2-200911070930 ./configure --includedir=/usr/include --libdir=/usr/lib64 --with-libdir=lib64 --without-pear --with-mysqli=shared,/usr/bin/mysql_config --enable-mbstring=shared --enable-mbregex --with-mssql=shared,/usr make -j3 make install # as root create /usr/local/etc/php.ini containing only the following: extension=mbstring.so extension=mssql.so extension=mysqli.so include_path=/path/to/pear/php $ /usr/local/bin/php -c /usr/local/etc/php.ini php-bug49098.php # script posted on 11 Aug Segmentation fault Commenting out EITHER extension=mbstring.so or extension=mssql.so in /usr/local/etc/php.ini stops the segfault. Can anyone else now reproduce this with the above environment? Is there any other information about the environment that I need to provide? [2009-09-26 10:54:13] t...@php.net 1. Still segfaults for me with the release version of 5.2.11, with MySQLi connection (mysql client libs and server 5.1.37). - Sriram, I also tried with your test script (just to make sure there wasn't a subtle difference from mine) and it also segfaulted. - Segfault is still in the same place as originally. 2. snap-200909261030 doesn't build atm (error in mysqli_api) What more info can I give to assist? [2009-09-24 19:32:19] srina...@php.net unable to reproduce with the earlier provided test case. so, need more information to reproduce / investigate this bug . also, would be useful to know if this still happens with either 5.2.11 (or latest svn snapshot) [2009-09-24 17:48:47] srina...@php.net i do have a wordpress running with php 5.2.11 for my site and i
#49098 [Fbk-Opn]: Using custom session handler causes segfault in session_save_state
ID: 49098 Updated by: t...@php.net Reported By: bugs at timj dot co dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux PHP Version: 5.2.10 New Comment: Recompiled with --enable-debug and -O1, the backtrace is very similar to that reported right at the start of the bug, and not very helpful: #0 0x00600d2d in _zend_mm_free_int () #1 0x00600fc9 in _efree () #2 0x005b651f in php_version_compare () #3 0x005b6596 in zif_version_compare () #4 0x0063df7a in zend_do_fcall_common_helper_SPEC () #5 0x0063e53f in ZEND_DO_FCALL_SPEC_CONST_HANDLER () #6 0x0063a63d in execute () #7 0x0063e076 in zend_do_fcall_common_helper_SPEC () #8 0x0063e453 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #9 0x0063a63d in execute () #10 0x0063e076 in zend_do_fcall_common_helper_SPEC () #11 0x0063e453 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #12 0x0063a63d in execute () #13 0x0063e076 in zend_do_fcall_common_helper_SPEC () #14 0x0063e453 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #15 0x0063a63d in execute () #16 0x0063e076 in zend_do_fcall_common_helper_SPEC () #17 0x0063e453 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #18 0x0063a63d in execute () #19 0x0060ff69 in zend_call_function () #20 0x0061021b in call_user_function_ex () #21 0x006103ef in call_user_function () #22 0x005146ac in ps_call_handler () #23 0x005148f4 in ps_write_user () #24 0x0050e381 in php_session_flush () #25 0x0050f4f6 in zm_deactivate_session () #26 0x0061b4be in module_registry_cleanup () #27 0x00623a51 in zend_hash_reverse_apply () #28 0x0061a1ff in zend_deactivate_modules () #29 0x005db184 in php_request_shutdown () #30 0x00683ecc in main () Now, what's really interesting is that with -O0 and the exact same configure options, the segfault doesn't happen. Maybe this helps to pinpoint the cause? Previous Comments: [2009-11-08 22:43:24] t...@php.net With my original compile as per instructions above (the compiler got -O2 by default): #0 _zend_mm_alloc_int (heap=0x9e32b0, size=12) at /path/to/php5.2-200911070930/Zend/zend_alloc.c:1785 #1 0x0048227e in php_pcre_match_impl (pce=value optimized out, subject=value optimized out, subject_len=value optimized out, return_value=value optimized out, subpats=0x0, global=0, use_flags=0, flags=value optimized out, start_offset=0) at /path/to/php5.2-200911070930/ext/pcre/php_pcre.c:603 #2 0x00482ccd in php_do_pcre_match (ht=2, return_value=0xd584a0, return_value_ptr=value optimized out, this_ptr=value optimized out, return_value_used=value optimized out, global=0) at /path/to/php5.2-200911070930/ext/pcre/php_pcre.c:513 #3 0x00659303 in zend_do_fcall_common_helper_SPEC ( execute_data=0x7fffc420) at /path/to/php5.2-200911070930/Zend/zend_vm_execute.h:200 #4 0x0065522c in execute (op_array=0xd83190) at /path/to/php5.2-200911070930/Zend/zend_vm_execute.h:92 #5 0x00658c76 in zend_do_fcall_common_helper_SPEC ( execute_data=0x7fffc740) at /path/to/php5.2-200911070930/Zend/zend_vm_execute.h:234 #6 0x0065522c in execute (op_array=0xd37808) at /path/to/php5.2-200911070930/Zend/zend_vm_execute.h:92 #7 0x00658c76 in zend_do_fcall_common_helper_SPEC ( execute_data=0x7fffd660) [2009-11-08 21:11:07] srina...@php.net thanks for taking time and trying to reproduce this issue. can u kindly provide / attach stack trace when this issue happens... this would help us identify us as to what is happening at ur end.. u can enable core dump by doing some thing like ulimit -c unlimited now, u can run your program to generate core dump and provide us the stack trace as mentioned in this below link.. http://bugs.php.net/bugs-generating-backtrace.php [2009-11-08 19:10:35] t...@php.net After spending an enormous amount of time testing endless combinations of compile and runtime options, I have hopefully found the key to solving this obscure bug. The segfault only happens specifically if the following is true: - the mbstring extension is enabled, *AND* - the mssql extension is enabled (particularly weird because the test script does not use mssql in any way) In the hope of making the reproduction scenario more robust, I have pared down the configure line to a minimum and here is the exact environment, from source tarball, which I can reproduce it in: OS: Fedora 11 x86_64 (fully updated as at 2009-11-08) Notable dependencies: mysql-devel
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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: Compiling with -O0 and *without* --enable-debug gives a backtrace which is almost (not quite) the same: #0 0x006bec94 in _zend_mm_free_int () #1 0x006bfb06 in _efree () #2 0x006546cf in php_version_compare () #3 0x0065474f in zif_version_compare () #4 0x0070a98a in zend_do_fcall_common_helper_SPEC () #5 0x0070e932 in ZEND_DO_FCALL_SPEC_CONST_HANDLER () #6 0x0070a480 in execute () #7 0x0070ab3b in zend_do_fcall_common_helper_SPEC () #8 0x0070b081 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #9 0x0070a480 in execute () #10 0x0070ab3b in zend_do_fcall_common_helper_SPEC () #11 0x0070b081 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #12 0x0070a480 in execute () #13 0x0070ab3b in zend_do_fcall_common_helper_SPEC () #14 0x0070b081 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #15 0x0070a480 in execute () #16 0x0070ab3b in zend_do_fcall_common_helper_SPEC () #17 0x0070b081 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #18 0x0070a480 in execute () #19 0x006d2340 in zend_call_function () #20 0x006d0651 in call_user_function_ex () #21 0x006d052c in call_user_function () #22 0x005718c9 in ps_call_handler () #23 0x00571d8c in ps_write_user () #24 0x0056ab00 in php_session_save_current_state () #25 0x0056e184 in php_session_flush () #26 0x00570395 in zm_deactivate_session () #27 0x006e7532 in module_registry_cleanup () #28 0x006ecf0f in zend_hash_reverse_apply () #29 0x006df855 in zend_deactivate_modules () #30 0x00689690 in php_request_shutdown () #31 0x00763bd4 in main () Previous Comments: [2009-11-08 22:44:30] t...@php.net Recompiled with --enable-debug and -O1, the backtrace is very similar to that reported right at the start of the bug, and not very helpful: #0 0x00600d2d in _zend_mm_free_int () #1 0x00600fc9 in _efree () #2 0x005b651f in php_version_compare () #3 0x005b6596 in zif_version_compare () #4 0x0063df7a in zend_do_fcall_common_helper_SPEC () #5 0x0063e53f in ZEND_DO_FCALL_SPEC_CONST_HANDLER () #6 0x0063a63d in execute () #7 0x0063e076 in zend_do_fcall_common_helper_SPEC () #8 0x0063e453 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #9 0x0063a63d in execute () #10 0x0063e076 in zend_do_fcall_common_helper_SPEC () #11 0x0063e453 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #12 0x0063a63d in execute () #13 0x0063e076 in zend_do_fcall_common_helper_SPEC () #14 0x0063e453 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #15 0x0063a63d in execute () #16 0x0063e076 in zend_do_fcall_common_helper_SPEC () #17 0x0063e453 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () #18 0x0063a63d in execute () #19 0x0060ff69 in zend_call_function () #20 0x0061021b in call_user_function_ex () #21 0x006103ef in call_user_function () #22 0x005146ac in ps_call_handler () #23 0x005148f4 in ps_write_user () #24 0x0050e381 in php_session_flush () #25 0x0050f4f6 in zm_deactivate_session () #26 0x0061b4be in module_registry_cleanup () #27 0x00623a51 in zend_hash_reverse_apply () #28 0x0061a1ff in zend_deactivate_modules () #29 0x005db184 in php_request_shutdown () #30 0x00683ecc in main () Now, what's really interesting is that with -O0 and the exact same configure options, the segfault doesn't happen. Maybe this helps to pinpoint the cause? [2009-11-08 22:43:24] t...@php.net With my original compile as per instructions above (the compiler got -O2 by default): #0 _zend_mm_alloc_int (heap=0x9e32b0, size=12) at /path/to/php5.2-200911070930/Zend/zend_alloc.c:1785 #1 0x0048227e in php_pcre_match_impl (pce=value optimized out, subject=value optimized out, subject_len=value optimized out, return_value=value optimized out, subpats=0x0, global=0, use_flags=0, flags=value optimized out, start_offset=0) at /path/to/php5.2-200911070930/ext/pcre/php_pcre.c:603 #2 0x00482ccd in php_do_pcre_match (ht=2, return_value=0xd584a0, return_value_ptr=value optimized out, this_ptr=value optimized out, return_value_used=value optimized out, global=0) at /path/to/php5.2-200911070930/ext/pcre/php_pcre.c:513 #3 0x00659303 in zend_do_fcall_common_helper_SPEC ( execute_data=0x7fffc420) at /path/to/php5.2-200911070930/Zend
#49098 [Fbk-Opn]: Using custom session handler causes segfault in session_save_state
ID: 49098 Updated by: t...@php.net Reported By: bugs at timj dot co dot uk -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux PHP Version: 5.2.10 New Comment: 1. Still segfaults for me with the release version of 5.2.11, with MySQLi connection (mysql client libs and server 5.1.37). - Sriram, I also tried with your test script (just to make sure there wasn't a subtle difference from mine) and it also segfaulted. - Segfault is still in the same place as originally. 2. snap-200909261030 doesn't build atm (error in mysqli_api) What more info can I give to assist? Previous Comments: [2009-09-24 19:32:19] srina...@php.net unable to reproduce with the earlier provided test case. so, need more information to reproduce / investigate this bug . also, would be useful to know if this still happens with either 5.2.11 (or latest svn snapshot) [2009-09-24 17:48:47] srina...@php.net i do have a wordpress running with php 5.2.11 for my site and i don't have any issues. if you do notice with the latest php build, if you can provide a test case to reproduce this bug that would be useful. as i noted earlier, i was not able to reproduce this bug with the provided test case here. [2009-09-18 19:43:06] ulf at ladb dot unm dot edu Hi, Is this bug still under investigation? Just wondering because 5.2.9 is the last version of PHP that works with Wordpress/MySQL without crashing Apache. Thanks. [2009-09-16 18:19:08] sriram dot natarajan at gmail dot com i just took the latest php snapshot from http://snaps.php.net and tried it out. if you notice, my script is just a completion of your script - i just filled in some missing pieces in your script - like creating the table etc . i am also using mysql 5.1.30 [2009-09-16 06:01:10] t...@php.net sriram: a) can you specify exactly which snapshot you use so that I can confirm/deny what you say b) did you try my test script? what does that do? why did you make up a new one? 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=49098edit=1
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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:
sriram:
a) can you specify exactly which snapshot you use so that I can
confirm/deny what you say
b) did you try my test script? what does that do? why did you make up a
new one?
Previous Comments:
[2009-09-16 02:26:55] sriram dot natarajan at gmail dot com
i just tried a simple php with mdb2/http_session2 with the latest php
snapshot and was not able to reproduce this issue. is there some thing
else required to reproduce this issue ?
here is the simple script that i had to try it out
?php
require_once 'MDB2.php';
require_once 'HTTP/Session2.php';
$dsn = 'mysqli://root:@localhost/mysql';
$mdb2 = MDB2::singleton($dsn);
$mdb2-loadModule('Manager');
$mdb2-loadModule('Extended');
$db = $mdb2-connect($dsn);
$table_fields = array
(
'id' = array(
'type' = 'text',
'length' = '32'),
'data' = array(
'type' = 'text',
'length' = '32'),
'skey' = array(
'type' = 'text',
'length' = '32'),
'expiry' = array(
'type' = 'integer',
'notnull' = 1,
'unsigned' = 0),
);
$table_constraints = array(
'primary' = true,
'fields' = array (
'id' = array()),
);
$s = $mdb2-createTable('session_data', $table_fields);
if (PEAR::isError($s)) {
die($s-getMessage() . ', ' . $s-getDebugInfo());
}
$mdb2-createConstraint('session_data',
'primary_key',$table_constraints);
$mdb2-createSequence('primary_key');
$options = array();
$options['dsn'] = $dsn;
$options['table'] = 'session_data';
HTTP_Session2::setContainer('MDB2', $options);
HTTP_Session2::start('MySESS');
HTTP_Session2::set('variable', 'The string');
?
[2009-09-04 11:30:40] t...@php.net
Further info: the crash does NOT occur if the DSN string is changed to
mysql://... instead of mysqli://... (this also seemed to be the case
in similar bug #48922)
[2009-08-11 22:00:51] t...@php.net
OK, for the record then, that case was reproducible for me with
5.2.11-dev snap 200908101630. Backtrace similar to the first one opening
the bug.
[2009-08-11 05:16:26] j...@php.net
NEVER ever email me privately test cases. Here's the script you sent
me:
?php
/*
CREATE TABLE `_session_data` (
`id` char(32) NOT NULL,
`expiry` int(10) unsigned NOT NULL,
`data` text NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
*/
require_once 'HTTP/Session2.php';
$dsn = 'mysqli://user:p...@localhost/dbname';
$options = array();
$options['dsn'] = $dsn;
$options['table'] = '_session_data';
HTTP_Session2::setContainer('MDB2', $options);
HTTP_Session2::start('mysess');
?
Installed PEAR packages to make it happen:
HTTP_Session2 0.7.2 beta
MDB2 2.5.0b2 beta
MDB2_Driver_mysqli 1.5.0b2 beta
[2009-07-29 12:31:10] j...@php.net
And as expected: We really need proper, short, reproducing script. Now
the problem might be anywhere..
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=49098edit=1
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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:
Further info: the crash does NOT occur if the DSN string is changed to
mysql://... instead of mysqli://... (this also seemed to be the case
in similar bug #48922)
Previous Comments:
[2009-08-11 22:00:51] t...@php.net
OK, for the record then, that case was reproducible for me with
5.2.11-dev snap 200908101630. Backtrace similar to the first one opening
the bug.
[2009-08-11 05:16:26] j...@php.net
NEVER ever email me privately test cases. Here's the script you sent
me:
?php
/*
CREATE TABLE `_session_data` (
`id` char(32) NOT NULL,
`expiry` int(10) unsigned NOT NULL,
`data` text NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
*/
require_once 'HTTP/Session2.php';
$dsn = 'mysqli://user:p...@localhost/dbname';
$options = array();
$options['dsn'] = $dsn;
$options['table'] = '_session_data';
HTTP_Session2::setContainer('MDB2', $options);
HTTP_Session2::start('mysess');
?
Installed PEAR packages to make it happen:
HTTP_Session2 0.7.2 beta
MDB2 2.5.0b2 beta
MDB2_Driver_mysqli 1.5.0b2 beta
[2009-07-29 12:31:10] j...@php.net
And as expected: We really need proper, short, reproducing script. Now
the problem might be anywhere..
[2009-07-29 12:30:18] j...@php.net
In the future: PLEASE add the backtraces in separate comments. Now it's
pretty hard to see which is which.
[2009-07-29 12:14:23] t...@php.net
N.B. this occurs with both apache2 and CGI SAPIs.
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=49098edit=1
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
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:
OK, for the record then, that case was reproducible for me with
5.2.11-dev snap 200908101630. Backtrace similar to the first one opening
the bug.
Previous Comments:
[2009-08-11 05:16:26] j...@php.net
NEVER ever email me privately test cases. Here's the script you sent
me:
?php
/*
CREATE TABLE `_session_data` (
`id` char(32) NOT NULL,
`expiry` int(10) unsigned NOT NULL,
`data` text NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
*/
require_once 'HTTP/Session2.php';
$dsn = 'mysqli://user:p...@localhost/dbname';
$options = array();
$options['dsn'] = $dsn;
$options['table'] = '_session_data';
HTTP_Session2::setContainer('MDB2', $options);
HTTP_Session2::start('mysess');
?
Installed PEAR packages to make it happen:
HTTP_Session2 0.7.2 beta
MDB2 2.5.0b2 beta
MDB2_Driver_mysqli 1.5.0b2 beta
[2009-07-29 12:31:10] j...@php.net
And as expected: We really need proper, short, reproducing script. Now
the problem might be anywhere..
[2009-07-29 12:30:18] j...@php.net
In the future: PLEASE add the backtraces in separate comments. Now it's
pretty hard to see which is which.
[2009-07-29 12:14:23] t...@php.net
N.B. this occurs with both apache2 and CGI SAPIs.
[2009-07-29 12:12:40] bugs at timj dot co dot uk
Description:
I am seeing segfaults on various pages that don't occur on 5.2.9 (and
the same site has been working on many previous versions of 5.1/5.2). I
have a session handler using PEAR HTTP_Session2, that saves via
MDB2/mysqli to a MySQL database. The segfaults seem to happen during
session_save_state.
Unfortunately I don't currently have a trivial reproduction scenario,
but it does reliably cause a segfault in both 5.2.10 and
5.2SVN-snap200907182030.
I am not a C developer but after a diligent attempt to search the
bugtracker and investigate the bug, I concluded that it was probably
duplicate of bug #48922 and tried to add additional information to that
bug, explaining my reasoning, to avoid filing a duplicate (in accordance
with http://bugs.php.net/report.php). However, Jani disagrees (see
comments in other bug), so I'm filing a new bug.
Actual result:
--
Here's 5.2.10: (crash in version_compare):
Program received signal SIGSEGV, Segmentation fault.
0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
1978if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
#1 0x71ea5af4 in _efree (ptr=0x78bb7010) at
/usr/src/debug/php-5.2.10/Zend/zend_alloc.c:2311
#2 0x71e3f4ff in php_version_compare
(orig_ver1=0x787b7538
5.2.10, orig_ver2=0x78e41ac0 5.0) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:202
#3 0x71e3f58b in zif_version_compare (ht=3,
return_value=0x787bc458, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:222
#4 0x71ef028d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:200
#5 0x71ef4235 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:1739
#6 0x71eefd6f in execute (op_array=0x78a028c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#7 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#8 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#9 0x71eefd6f in execute (op_array=0x78b696e8) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#10 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#11 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#12 0x71eefd6f in execute (op_array=0x78b69588) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#13 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffc2d0
#49098 [NEW]: Using custom session handler causes segfault in session_save_state
From: bugs at timj dot co dot uk
Operating system: Linux
PHP version: 5.2.10
PHP Bug Type: Reproducible crash
Bug description: Using custom session handler causes segfault in
session_save_state
Description:
I am seeing segfaults on various pages that don't occur on 5.2.9 (and the
same site has been working on many previous versions of 5.1/5.2). I have a
session handler using PEAR HTTP_Session2, that saves via MDB2/mysqli to a
MySQL database. The segfaults seem to happen during session_save_state.
Unfortunately I don't currently have a trivial reproduction scenario, but
it does reliably cause a segfault in both 5.2.10 and
5.2SVN-snap200907182030.
I am not a C developer but after a diligent attempt to search the
bugtracker and investigate the bug, I concluded that it was probably
duplicate of bug #48922 and tried to add additional information to that
bug, explaining my reasoning, to avoid filing a duplicate (in accordance
with http://bugs.php.net/report.php). However, Jani disagrees (see comments
in other bug), so I'm filing a new bug.
Actual result:
--
Here's 5.2.10: (crash in version_compare):
Program received signal SIGSEGV, Segmentation fault.
0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
1978if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
#1 0x71ea5af4 in _efree (ptr=0x78bb7010) at
/usr/src/debug/php-5.2.10/Zend/zend_alloc.c:2311
#2 0x71e3f4ff in php_version_compare (orig_ver1=0x787b7538
5.2.10, orig_ver2=0x78e41ac0 5.0) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:202
#3 0x71e3f58b in zif_version_compare (ht=3,
return_value=0x787bc458, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:222
#4 0x71ef028d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:200
#5 0x71ef4235 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:1739
#6 0x71eefd6f in execute (op_array=0x78a028c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#7 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#8 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#9 0x71eefd6f in execute (op_array=0x78b696e8) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#10 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#11 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#12 0x71eefd6f in execute (op_array=0x78b69588) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#13 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#14 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#15 0x71eefd6f in execute (op_array=0x78b6a728) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#16 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#17 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#18 0x71eefd6f in execute (op_array=0x78e29300) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#19 0x71eb816b in zend_call_function (fci=0x7fffd440,
fci_cache=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:1032
#20 0x71eb66d4 in call_user_function_ex
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr_ptr=0x7fffd4e8,
param_count=2, params=0x787b7670, no_separation=1,
symbol_table=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:640
#21 0x71eb65af in call_user_function
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr=0x787b7c18, param_count=2,
params=0x7fffd590)
at /usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:613
#22 0x71da4785 in ps_call_handler (func=0x78e3eea0, argc=2,
argv=0x7fffd590) at
/usr/src/debug/php-5.2.10/ext/session/mod_user.c:53
#23 0x71da4c2d in ps_write_user (mod_data=0x7221db60,
key=0x78e3f7c0 59ufo7hqslet38p73jp9na8577
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
ID: 49098
Updated by: t...@php.net
Reported By: bugs at timj dot co dot uk
Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.2.10
New Comment:
N.B. this occurs with both apache2 and CGI SAPIs.
Previous Comments:
[2009-07-29 12:12:40] bugs at timj dot co dot uk
Description:
I am seeing segfaults on various pages that don't occur on 5.2.9 (and
the same site has been working on many previous versions of 5.1/5.2). I
have a session handler using PEAR HTTP_Session2, that saves via
MDB2/mysqli to a MySQL database. The segfaults seem to happen during
session_save_state.
Unfortunately I don't currently have a trivial reproduction scenario,
but it does reliably cause a segfault in both 5.2.10 and
5.2SVN-snap200907182030.
I am not a C developer but after a diligent attempt to search the
bugtracker and investigate the bug, I concluded that it was probably
duplicate of bug #48922 and tried to add additional information to that
bug, explaining my reasoning, to avoid filing a duplicate (in accordance
with http://bugs.php.net/report.php). However, Jani disagrees (see
comments in other bug), so I'm filing a new bug.
Actual result:
--
Here's 5.2.10: (crash in version_compare):
Program received signal SIGSEGV, Segmentation fault.
0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
1978if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
#1 0x71ea5af4 in _efree (ptr=0x78bb7010) at
/usr/src/debug/php-5.2.10/Zend/zend_alloc.c:2311
#2 0x71e3f4ff in php_version_compare
(orig_ver1=0x787b7538
5.2.10, orig_ver2=0x78e41ac0 5.0) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:202
#3 0x71e3f58b in zif_version_compare (ht=3,
return_value=0x787bc458, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:222
#4 0x71ef028d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:200
#5 0x71ef4235 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:1739
#6 0x71eefd6f in execute (op_array=0x78a028c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#7 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#8 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#9 0x71eefd6f in execute (op_array=0x78b696e8) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#10 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#11 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#12 0x71eefd6f in execute (op_array=0x78b69588) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#13 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#14 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#15 0x71eefd6f in execute (op_array=0x78b6a728) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#16 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#17 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#18 0x71eefd6f in execute (op_array=0x78e29300) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#19 0x71eb816b in zend_call_function (fci=0x7fffd440,
fci_cache=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:1032
#20 0x71eb66d4 in call_user_function_ex
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr_ptr=0x7fffd4e8,
param_count=2, params=0x787b7670, no_separation=1,
symbol_table=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:640
#21 0x71eb65af in call_user_function
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr=0x787b7c18,
param_count=2,
params=0x7fffd590)
at /usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:613
#22 0x71da4785 in ps_call_handler (func
#48922 [NoF-Opn]: session_set_save_handler() appears to cause all processing to stop
ID: 48922
Updated by: t...@php.net
Reported By: bobby at indesignfirm dot com
-Status: No Feedback
+Status: Open
Bug Type: Session related
Operating System: RedHat 2.6.9-42.0.8.EL #1
PHP Version: 5.2.10
Previous Comments:
[2009-07-26 01:00:01] 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.
[2009-07-18 22:04:39] t...@php.net
I *think* I have the same problem. Segfaults on various pages that
don't occur on 5.2.9. I have a session handler using PEAR HTTP_Session,
that saves via MDB2/mysqli to a MySQL database. The common factor seems
to be that they happen during session_save_state.
Here's 5.2.10: (crash in version_compare):
Program received signal SIGSEGV, Segmentation fault.
0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
1978if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
#1 0x71ea5af4 in _efree (ptr=0x78bb7010) at
/usr/src/debug/php-5.2.10/Zend/zend_alloc.c:2311
#2 0x71e3f4ff in php_version_compare (orig_ver1=0x787b7538
5.2.10, orig_ver2=0x78e41ac0 5.0) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:202
#3 0x71e3f58b in zif_version_compare (ht=3,
return_value=0x787bc458, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:222
#4 0x71ef028d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:200
#5 0x71ef4235 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:1739
#6 0x71eefd6f in execute (op_array=0x78a028c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#7 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#8 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#9 0x71eefd6f in execute (op_array=0x78b696e8) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#10 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#11 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#12 0x71eefd6f in execute (op_array=0x78b69588) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#13 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#14 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#15 0x71eefd6f in execute (op_array=0x78b6a728) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#16 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#17 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#18 0x71eefd6f in execute (op_array=0x78e29300) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#19 0x71eb816b in zend_call_function (fci=0x7fffd440,
fci_cache=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:1032
#20 0x71eb66d4 in call_user_function_ex
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr_ptr=0x7fffd4e8,
param_count=2, params=0x787b7670, no_separation=1,
symbol_table=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:640
#21 0x71eb65af in call_user_function
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr=0x787b7c18, param_count=2,
params=0x7fffd590)
at /usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:613
#22 0x71da4785 in ps_call_handler (func=0x78e3eea0, argc=2,
argv=0x7fffd590) at
/usr/src/debug/php-5.2.10/ext/session/mod_user.c:53
#23 0x71da4c2d in ps_write_user (mod_data=0x7221db60,
key=0x78e3f7c0 59ufo7hqslet38p73jp9na8577,
val=0x78fb1e88
#48922 [Fbk]: session_set_save_handler() appears to cause all processing to stop
ID: 48922
Updated by: t...@php.net
Reported By: bobby at indesignfirm dot com
Status: Feedback
Bug Type: Session related
Operating System: RedHat 2.6.9-42.0.8.EL #1
PHP Version: 5.2.10
New Comment:
I *think* I have the same problem. Segfaults on various pages that
don't occur on 5.2.9. I have a session handler using PEAR HTTP_Session,
that saves via MDB2/mysqli to a MySQL database. The common factor seems
to be that they happen during session_save_state.
Here's 5.2.10: (crash in version_compare):
Program received signal SIGSEGV, Segmentation fault.
0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
1978if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
#1 0x71ea5af4 in _efree (ptr=0x78bb7010) at
/usr/src/debug/php-5.2.10/Zend/zend_alloc.c:2311
#2 0x71e3f4ff in php_version_compare (orig_ver1=0x787b7538
5.2.10, orig_ver2=0x78e41ac0 5.0) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:202
#3 0x71e3f58b in zif_version_compare (ht=3,
return_value=0x787bc458, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:222
#4 0x71ef028d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:200
#5 0x71ef4235 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:1739
#6 0x71eefd6f in execute (op_array=0x78a028c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#7 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#8 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#9 0x71eefd6f in execute (op_array=0x78b696e8) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#10 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#11 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#12 0x71eefd6f in execute (op_array=0x78b69588) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#13 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#14 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#15 0x71eefd6f in execute (op_array=0x78b6a728) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#16 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#17 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#18 0x71eefd6f in execute (op_array=0x78e29300) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#19 0x71eb816b in zend_call_function (fci=0x7fffd440,
fci_cache=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:1032
#20 0x71eb66d4 in call_user_function_ex
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr_ptr=0x7fffd4e8,
param_count=2, params=0x787b7670, no_separation=1,
symbol_table=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:640
#21 0x71eb65af in call_user_function
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr=0x787b7c18, param_count=2,
params=0x7fffd590)
at /usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:613
#22 0x71da4785 in ps_call_handler (func=0x78e3eea0, argc=2,
argv=0x7fffd590) at
/usr/src/debug/php-5.2.10/ext/session/mod_user.c:53
#23 0x71da4c2d in ps_write_user (mod_data=0x7221db60,
key=0x78e3f7c0 59ufo7hqslet38p73jp9na8577,
val=0x78fb1e88
__HTTP_Session2_Info|i:2;__HTTP_Session2_Idle|i:3600;__HTTP_Session2_Idle_TS|i:1247951369;user_id|s:1:\6\;audit_user|N;,
vallen=119) at /usr/src/debug/php-5.2.10/ext/session/mod_user.c:141
#24 0x71d9d8ba in php_session_save_current_state () at
/usr/src/debug/php-5.2.10/ext/session/session.c:556
#25 0x71da0fbb in php_session_flush () at
/usr/src/debug/php-5.2.10/ext/session/session.c:1408
#26 0x71da31cc in zm_deactivate_session (type=1,
module_number=17) at
/usr/src/debug/php-5.2.10/ext/session/session.c:2010
#27 0x71ecd24b in
#45956 [NEW]: Design problem: parse_ini_file lacks ability to handle errors gracefully
From: bugs at timj dot co dot uk
Operating system: irrelevant
PHP version: 5.2.6
PHP Bug Type: Filesystem function related
Bug description: Design problem: parse_ini_file lacks ability to handle errors
gracefully
Description:
This seems to be a design error rather than a bug: parse_ini_file() does
not provide any way to handle errors gracefully. In the event of a syntax
error, it throws an E_WARNING *but* the return value is simply an empty
array (the same as a - valid - empty file) instead of FALSE. Thus there is
no way to trap the error (via @ prefix) and handle it in a more graceful
way than an E_WARNING.
I would argue that changing the return value to FALSE in the case of an
invalid file is a reasonable change, since the only situations it will
break are ones where currently PHP throws a warning anyway.
Reproduce code:
---
This is what it would be nice to be able to do:
$ini = @parse_ini_file('some_invalid.ini');
if ($ini === false) {
// error: do something graceful
}
// normal execution
Expected result:
The code section // do something graceful executes
Actual result:
--
The code section // normal execution executes
--
Edit bug report at http://bugs.php.net/?id=45956edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45956r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45956r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45956r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45956r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45956r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45956r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45956r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45956r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45956r=support
Expected behavior:http://bugs.php.net/fix.php?id=45956r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45956r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45956r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45956r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45956r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45956r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45956r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45956r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45956r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45956r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45956r=mysqlcfg
#33039 [Bgs]: on shutdown: Notice: Unknown: Mailbox is empty (errflg=1) in Unknown on line 0
ID: 33039
Updated by: [EMAIL PROTECTED]
Reported By: mpb dot mail at gmail dot com
Status: Bogus
Bug Type: IMAP related
Operating System: *
PHP Version: 5.*, 4.*
Assigned To: sniper
New Comment:
I think the key point here is that imap_errors() should be called after
doing the imap_open(), which would clear the error stack and stop PHP
throwing E_NOTICEs.
This isn't very clear in the manual, which is arguably a doc bug.
Previous Comments:
[2005-05-19 15:38:41] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
On request termination PHP flushes all not yet reported IMAP errors at
E_NOTICE error reporting level. The fact there are any is the result of
the IMAP library reporting them.
[2005-05-16 08:35:15] mpb dot mail at gmail dot com
Description:
If you imap_open an empty pop mailbox, a Mailbox is empty (errflg=1)
notice will be printed during PHP's shutdown or cleanup phase after
your script has finished running (assuming E_NOTICE is set, of course).
As there is nothing wrong with having an empty mailbox, I believe that
PHP should not print this notice. I suspect that PHP is misinterpreting
a return code from the IMAP library, or is making an unnecessary call to
the IMAP library. It is also possible that the IMAP library is buggy
and should not be returning an errflg=1 (whatever that means).
If, in the reproduce code, you uncomment the final ini_set then the
notice will not be printed (as E_NOTICE is no longer set during PHP's
shutdown).
If you are unable to reproduce this problem with the empty POP mailbox
of your choice, let me know and I will set up a POP mailbox for you to
test against.
See also bug 7207.
Reproduce code:
---
ini_set ('error_reporting', E_ALL);
$imap = imap_open
( '{host.com:110/pop/novalidate-cert}INBOX',
'user', 'password' );
trigger_error ('test notice');
sleep (5);
// ini_set ('error_reporting', E_ALL ^ E_NOTICE);
Expected result:
Notice: test notice in /root/pinstall/local/vl0/test.php on line 8
Actual result:
--
Notice: test notice in /root/pinstall/local/vl0/test.php on line 8
Notice: Unknown: Mailbox is empty (errflg=1) in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=33039edit=1
