#49098 [Opn-Fbk]: Using custom session handler causes segfault in session_save_state

2009-11-11 Thread jani 
 ID:   49098
 Updated by:   j...@php.net
 Reported By:  bugs at timj dot co dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

To narrow this down a bit: Does it happen with latest PHP 5.3 snapshot?


Previous Comments:


[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 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

#49098 [Opn-Fbk]: Using custom session handler causes segfault in session_save_state

2009-11-11 Thread jani 
 ID:   49098
 Updated by:   j...@php.net
 Reported By:  bugs at timj dot co dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

What's the valgrind output then, same as before?


Previous Comments:


[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.





[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




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-Fbk]: Using custom session handler causes segfault in session_save_state

2009-11-09 Thread jani 
 ID:   49098
 Updated by:   j...@php.net
 Reported By:  bugs at timj dot co dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

Try with valgrind:

# USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cli/php
yourscript.php



Previous Comments:


[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 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 ()



[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

#49098 [Opn-Fbk]: Using custom session handler causes segfault in session_save_state

2009-11-08 Thread srinatar 
 ID:   49098
 Updated by:   srina...@php.net
 Reported By:  bugs at timj dot co dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

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


Previous Comments:


[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 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.



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-Fbk]: Using custom session handler causes segfault in session_save_state

2009-09-24 Thread srinatar 
 ID:   49098
 Updated by:   srina...@php.net
 Reported By:  bugs at timj dot co dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

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)


Previous Comments:


[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? 



[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');

?



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-Fbk]: Using custom session handler causes segfault in session_save_state

2009-07-29 Thread jani 
 ID:   49098
 Updated by:   j...@php.net
 Reported By:  bugs at timj dot co dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

And as expected: We really need proper, short, reproducing script. Now
the problem might be anywhere..


Previous Comments:


[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) 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,