Can you also try to compile your PHP with --enable-debug so 
that the backtrace is more informative.

#1  0x00002af677a1970e in zend_mm_panic (message=0x2af677b5ade9 "Heap corrupted")
    at /local/local/bodegon/php-debug/Zend/zend_alloc.c:61
No locals.
#2  0x00002af677a19c00 in zend_mm_remove_from_free_list (heap=0x555555867130, mm_block=0x2af679814fc0)
    at /local/local/bodegon/php-debug/Zend/zend_alloc.c:473
        prev = (zend_mm_free_block *) 0x555555867268
        next = (zend_mm_free_block *) 0x3631f6792bdbc8
#3  0x00002af677a1c39a in _zend_mm_realloc_int (heap=0x555555867130, p=0x2af6797d5060, size=262104,
    __zend_filename=0x2af677b3bb78 "/local/local/bodegon/php-debug/ext/standard/var.c", __zend_lineno=531,
    __zend_orig_filename=0x0, __zend_orig_lineno=0) at /local/local/bodegon/php-debug/Zend/zend_alloc.c:1450
        mm_block = (zend_mm_block *) 0x2af6797d5020
        next_block = (zend_mm_block *) 0x2af679814fc0
        true_size = 262176
        ptr = (void *) 0x23a8
#4  0x00002af677a1cae6 in _erealloc (ptr=0x2af6797d5060, size=262104, allow_failure=0,
    __zend_filename=0x2af677b3bb78 "/local/local/bodegon/php-debug/ext/standard/var.c", __zend_lineno=531,
    __zend_orig_filename=0x0, __zend_orig_lineno=0) at /local/local/bodegon/php-debug/Zend/zend_alloc.c:1633
No locals.
#5  0x00002af6779a8e47 in php_var_serialize_long (buf=0x7fff362aa7a0, val=407)
    at /local/local/bodegon/php-debug/ext/standard/var.c:531
        __nl = 261975
        __dest = (smart_str *) 0x7fff362aa7a0
#6  0x00002af6779a84f0 in php_var_serialize_intern (buf=0x7fff362aa7a0, struc=0x2af678c00088, var_hash=0x7fff362aa750)
    at /local/local/bodegon/php-debug/ext/standard/var.c:807
        key = 0x2af6785dc9c0 "hililist"
        data = (zval **) 0x2af6787d9060
        key_len = 9
        index = 407
        pos = (HashPosition) 0x2af6787d8e40
        incomplete_class = 0 '\0'
        i = 2
        var_already = (ulong *) 0x555555867268
        myht = (HashTable *) 0x2af6791b4710
#7  0x00002af6779a9326 in php_var_serialize (buf=0x7fff362aa7a0, struc=0x2af678c00088, var_hash=0x7fff362aa750)
    at /local/local/bodegon/php-debug/ext/standard/var.c:845
No locals.
#8  0x00002af6778ad8d5 in ps_srlzr_encode_php (newstr=0x7fff362aa808, newlen=0x7fff362aa82c)
    at /local/local/bodegon/php-debug/ext/session/session.c:479
        _ht = (HashTable *) 0x2af6785592d0
---Type <return> to continue, or q <return> to quit---
        buf = {
  c = 0x2af6797d5060 "gettext_php_loaded|b:0;gettext_php_domain|s:0:\"\";gettext_php_dir|s:0:\"\";gettext_php_translateStrings|a:0:{}gettext_php_loaded_language|s:0:\"\";gettext_php_short_circuit|b:0;sq_base_url|s:27:\"http://hel"..., len = 261973,
  a = 262103}
        var_hash = {nTableSize = 16384, nTableMask = 16383, nNumOfElements = 8427, nNextFreeElement = 988,
  pInternalPointer = 0x2af678f40f08, pListHead = 0x2af678f40f08, pListTail = 0x2af6794865f0, arBuckets = 0x2af6791b4f48,
  pDestructor = 0, persistent = 0 '\0', nApplyCount = 0 '\0', bApplyProtection = 1 '\001', inconsistent = 0}
        key = 0x2af678c000b0 "msgs"
        key_length = 4
        num_key = 47238021375260
        struc = (zval **) 0x2af678c00088
#9  0x00002af6778ae43d in php_session_encode (newlen=0x7fff362aa82c)
    at /local/local/bodegon/php-debug/ext/session/session.c:581
        ret = 0x0
#10 0x00002af6778aefb2 in php_session_save_current_state () at /local/local/bodegon/php-debug/ext/session/session.c:860
        val = 0x3 <Address 0x3 out of bounds>
        vallen = 0
        ret = -1
#11 0x00002af6778b3f3d in php_session_flush () at /local/local/bodegon/php-debug/ext/session/session.c:1845
        orig_bailout = (jmp_buf *) 0x7fff362aa9c0
        bailout = {{__jmpbuf = {160, -72001594702856356, 93824996795000, 93824995284840, 93824993674584, 93824993672000,
      -72001594702856596, -71943351702066904}, __mask_was_saved = 0, __saved_mask = {__val = {47238068320056, 0,
        47238068320144, 88, 2840945349788, 47238058731560, 47238060414864, 140734102153504, 88, 140734102153536,
        47238057413229, 140734102153536, 0, 0, 3017073977613, 47238058478808}}}}
#12 0x00002af6778b3f86 in zm_deactivate_session (type=1, module_number=12)
    at /local/local/bodegon/php-debug/ext/session/session.c:1859
No locals.
#13 0x00002af677a46705 in module_registry_cleanup (module=0x5555558b2e90)
    at /local/local/bodegon/php-debug/Zend/zend_API.c:1945
No locals.
#14 0x00002af677a4c4f3 in zend_hash_apply (ht=0x2af677cf99a0, apply_func=0x2af677a466ca <module_registry_cleanup>)
    at /local/local/bodegon/php-debug/Zend/zend_hash.c:666
        p = (Bucket *) 0x5555558b2e30
#15 0x00002af677a3d635 in zend_deactivate_modules () at /local/local/bodegon/php-debug/Zend/zend.c:817
        orig_bailout = (jmp_buf *) 0x0
        bailout = {{__jmpbuf = {160, -72001594702857076, 93824996795000, 93824995284840, 93824993674584, 93824993672000,
      -72001594702856228, -71943351700553726}, __mask_was_saved = 0, __saved_mask = {__val = {0, 47238055284985, 0,
        19188171792, 47238060396720, 13793667680, 47238068320208, 140734102153824, 47238055285156, 345, 4294967315, 160,
        18374742479006693916, 93824996795000, 93824995284840, 93824993674584}}}}
#16 0x00002af6779df423 in php_request_shutdown (dummy=0x0) at /local/local/bodegon/php-debug/main/main.c:1284
        report_memleaks = 1 '\001'
---Type <return> to continue, or q <return> to quit---
#17 0x00002af677ac34a3 in php_apache_request_dtor (r=0x5555559ae278)
    at /local/local/bodegon/php-debug/sapi/apache2handler/sapi_apache2.c:451
No locals.
#18 0x00002af677ac3dca in php_handler (r=0x5555559ae278)
    at /local/local/bodegon/php-debug/sapi/apache2handler/sapi_apache2.c:609
        ctx = (php_struct * volatile) 0x5555559ab718
        conf = (void *) 0x5555559aae48
        brigade = (apr_bucket_brigade * volatile) 0x5555559bd640
        bucket = (apr_bucket *) 0x5555556b4558
        rv = 21845
        parent_req = (request_rec * volatile) 0x0
#19 0x000055555558c6ba in ap_run_handler () from /usr/sbin/httpd2
No symbol table info available.
#20 0x000055555558faa2 in ap_invoke_handler () from /usr/sbin/httpd2
No symbol table info available.
#21 0x000055555559a1c8 in ap_process_request () from /usr/sbin/httpd2
No symbol table info available.
#22 0x0000555555597409 in ap_register_input_filter () from /usr/sbin/httpd2
No symbol table info available.
#23 0x0000555555593772 in ap_run_process_connection () from /usr/sbin/httpd2
No symbol table info available.
#24 0x000055555559dc09 in ap_graceful_stop_signalled () from /usr/sbin/httpd2
No symbol table info available.
#25 0x000055555559de0e in ap_graceful_stop_signalled () from /usr/sbin/httpd2
No symbol table info available.
#26 0x000055555559e911 in ap_mpm_run () from /usr/sbin/httpd2
No symbol table info available.
#27 0x0000555555579cb8 in main () from /usr/sbin/httpd2
No symbol table info available.
(gdb)

update summary.

Could you also please try to see if valgrind tells you anything?

valgrind --tool=memcheck --log-file=httpd /path/to/apache/httpd -X

And check out httpd.<PID> file.

Obviously the new heap implementation from Zend is unstable.

took me a while to reproduce it again, oO.

that 's whaT I obtained with valgrind.

==15053== Conditional jump or move depends on uninitialised value(s)
==15053==    at 0x59E1002: vfprintf (in /lib64/libc-2.4.so)
==15053==    by 0x59FE6F8: vsprintf (in /lib64/libc-2.4.so)
==15053==    by 0x59E91A7: sprintf (in /lib64/libc-2.4.so)
==15053==    by 0x7D120DA: _convert_to_string (zend_operators.c:556)
==15053==    by 0x7D1A6C2: zend_make_printable_zval (zend.c:266)
==15053==    by 0x7D58B84: ZEND_ADD_VAR_SPEC_TMP_CV_HANDLER (zend_vm_execute.h:6552)
==15053==    by 0x7D4407E: execute (zend_vm_execute.h:92)
==15053==    by 0x7D4480F: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234)
==15053==    by 0x7D454AD: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322)
==15053==    by 0x7D4407E: execute (zend_vm_execute.h:92)
==15053==    by 0x7D1C4DA: zend_execute_scripts (zend.c:1095)
==15053==    by 0x7CBE341: php_execute_script (main.c:1759)
==15053==
==15053== Process terminating with default action of signal 11 (SIGSEGV)
==15053==  Bad permissions for mapped region at address 0x18
==15053==    at 0x7CF7D50: zend_mm_add_to_free_list (zend_alloc.c:465)
==15053==    by 0x7CF986B: _zend_mm_alloc_int (zend_alloc.c:1233)
==15053==    by 0x7CFA7C5: _zend_mm_realloc_int (zend_alloc.c:1543)
==15053==    by 0x7CFAAE5: _erealloc (zend_alloc.c:1633)
==15053==    by 0x7C82C92: php_var_serialize_string (var.c:540)
==15053==    by 0x7C8650F: php_var_serialize_intern (var.c:810)
==15053==    by 0x7C86709: php_var_serialize_intern (var.c:827)
==15053==    by 0x7C87325: php_var_serialize (var.c:845)
==15053==    by 0x7B8B8D4: ps_srlzr_encode_php (session.c:479)
==15053==    by 0x7B8C43C: php_session_encode (session.c:581)
==15053==    by 0x7B8CFB1: php_session_save_current_state (session.c:860)
==15053==    by 0x7B91F3C: php_session_flush (session.c:1845)
==15053==
==15053== ERROR SUMMARY: 63 errors from 13 contexts (suppressed: 155 from 1)
==15053== malloc/free: in use at exit: 20,326,987 bytes in 11,487 blocks.
==15053== malloc/free: 214,233 allocs, 202,746 frees, 315,649,047 bytes allocated.
==15053== For counts of detected errors, rerun with: -v
==15053== searching for pointers to 11,487 not-freed blocks.
==15053== checked 17,712,560 bytes.
==15053==
==15053== LEAK SUMMARY:
==15053==    definitely lost: 924 bytes in 35 blocks.
==15053==      possibly lost: 0 bytes in 0 blocks.
==15053==    still reachable: 20,326,063 bytes in 11,452 blocks.
==15053==         suppressed: 0 bytes in 0 blocks.
==15053== Use --leak-check=full to see details of leaked memory.
hell:~ #

well. additionally , this is a 64bit machine,but can be reproduced in IIRC can be reproduced in 32 bit too. it linux with latest 5.2 CVS, also reproduced in "released" RC2 tarball. 

not reproducible with 5.1.x cause this is caused by the new memory manager.

A trace with xdebug loaded also ends abruptly in random places.. sometimes just after end of an IMAP stream,

                                   >=> ' Logout completed.\r\n'
    6.4978    9175040             -> trim(' Logout completed.\r\n') /srv/www/htdocs/squirrelmail/functions/imap_general.php:203
                                   >=> 'Logout completed.'
                                 >=> array (0 => array (0 => '* BYE Logging out\r\n'))
                               >=> array (0 => '* BYE Logging out\r\n')
                             >=> array (0 => '* BYE Logging out\r\n')
                           >=> NULL
                         >=> 1
    6.5415    5767168
TRACE END   [2006-08-20 18:37:19]

or in other ocassions (weird) it segfaults **just after that** when squirelmail tries to register and object in a session , session variable si created and then die, :(

also, the random error happends not only with right_main.php of SM but with read_body.php or the simple login.php.

Im done, I don't know how else to look, not sure If I can provide reproduce code either. any clues ?

Which Apache version is used and what is the MPM ?

apache 2.2.X with prefork MPM

I've tested it on 3 different machines (1 x86 and 2 x86-64) and I can't see any crashes whatsoever.
Please try to reduce the reproduce code and/or provide access to the machine where it's reproducible.

Tony, were you tested.. IMAP server was in the same machine or in a remote machine.. ? I think that counts for this problem. I cannot get this crash when imap server is in localhost.

ok. I now checked a fresh copy from the cvs, and reduced my php installation to the really minimum to run the offended app that crashes.

my configure line now is :

./configure --enable-debug --with-pcre-regex --with-iconv --enable-session --disable-all --with-libdir=lib64 --with      -apxs2=/usr/sbin/apxs2

results :

imap server in remote === RANDOM CRASH
imap server in localhost === NO CRASH.

the gdb and valgrind info are the same.

No, using IMAP server on a different machine didn't change anything. It still works fine without any crashes.

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. 

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.

Well, we still need a reproduce case..

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.

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 :)

Christian, what version of SquirrelMail did you use?

tony, Im using 1.4.x Tree from CVS.
I hope somebody else can reproduce it, due to the random nature of the problem, is hard to get a short reproduce code... :-(

BTW... I just tested again with a fresh cvs checkout and :

Squirrelmail 1.4 == segfaulted just after loggin, with the same backtrace.

Squirrelmail 1.5devel == no segfault, probably 'cause that release doesn't contains the code that triggers this crash.

in response james at digisys dot net :

regardless what the squirrelmail pages says, it has worked pretty fine for us in PHP 5.1.x , and anyway, no userspace code should crash the engine, or at least, not randomly :-)

Please retest it with 5.2.0RC3. The bug should be fixed there.

there was a glitch in my CVS copy that for some reason, it haven't a current version of zend_alloc.c , instead , my zend directory had a previuos version.

this is fixed, I can't reproduce it anymore *g*.

thanks folks.closed