ID: 38525
Updated by: [EMAIL PROTECTED]
Reported By: judas dot iscariote at gmail dot com
Status: Feedback
Bug Type: Reproducible crash
Operating System: linux
PHP Version: 5.2.0RC2
New Comment:
Christian, what version of SquirrelMail did you use?
Previous Comments:
------------------------------------------------------------------------
[2006-08-28 01:19:15] james at digisys dot net
FWIW, I'm seeing these same random seg faults with PHP 5.1.4 and
Squirrelmail 1.4.8 with an external IMAP server. Switching to the
development branch of Squirrelmail (1.5.2) cleared things up.
According to the Squirrelmail site the current stable releases (1.4.x)
do not work with PHP5, but the CVS version contains fixes which get it
working. Not that PHP should fault either way :)
------------------------------------------------------------------------
[2006-08-26 09:35:25] poeml at suse dot de
Hi,
on my machine it happens with IMAP server _on localhost_.
A how-to-reproduce procedure here is:
- open inbox in browser
- open first mail
- click "next mail"
- proceed with clicking "next mail" (thereby stepping
through mailbox mail by mail), until segfault happens.
Sometimes it takes a while, but il WILL happen sooner or
later.
- now, reloading will trigger the segfault again and again.
- viewing the next mail and going back shows the mail
without segfault. This also allows to continue to use
squirrelmail until the next segfault is encountered.
------------------------------------------------------------------------
[2006-08-23 23:06:11] [EMAIL PROTECTED]
Well, we still need a reproduce case..
------------------------------------------------------------------------
[2006-08-23 22:52:46] judas dot iscariote at gmail dot com
Tony :
Sadly I still get a segfault with a fresh CVS copy :-(
=32459== Process terminating with default action of signal 11
(SIGSEGV)
==32459== Bad permissions for mapped region at address 0x18
==32459== at 0x7BEC108: zend_mm_add_to_free_list (zend_alloc.c:465)
==32459== by 0x7BEDC23: _zend_mm_alloc_int (zend_alloc.c:1233)
==32459== by 0x7BEEB7D: _zend_mm_realloc_int (zend_alloc.c:1543)
==32459== by 0x7BEEE9D: _erealloc (zend_alloc.c:1633)
==32459== by 0x7B84771: php_var_serialize_string (var.c:538)
==32459== by 0x7B86607: php_var_serialize_intern (var.c:701)
==32459== by 0x7B88679: php_var_serialize_intern (var.c:827)
==32459== by 0x7B88679: php_var_serialize_intern (var.c:827)
==32459== by 0x7B89295: php_var_serialize (var.c:845)
==32459== by 0x7B00700: ps_srlzr_encode_php (session.c:479)
==32459== by 0x7B01268: php_session_encode (session.c:581)
==32459== by 0x7B01DDD: php_session_save_current_state
(session.c:860)
==32459==
==32459== ERROR SUMMARY: 26 errors from 8 contexts (suppressed: 149
from 1)
==32459== malloc/free: in use at exit: 21,210,557 bytes in 5,186
blocks.
==32459== malloc/free: 169,756 allocs, 164,570 frees, 216,925,409 bytes
allocated.
==32459== For counts of detected errors, rerun with: -v
==32459== searching for pointers to 5,186 not-freed blocks.
==32459== checked 19,498,696 bytes.
------------------------------------------------------------------------
[2006-08-23 13:04:57] [EMAIL PROTECTED]
This seems to be a duplicate of bug #38265.
Dmitry has committed a patch for it several minutes ago, please try the
next snapshot (or CVS sources).
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/38525
--
Edit this bug report at http://bugs.php.net/?id=38525&edit=1
