Not a bug in PHP but in the c-client. Please report this 
to the c-client authors.

Would agree this is a c-client bug from the bt, unfortunately this problem keeps jumping around, sometimes ending at execute(), sometimes ending up in internal OS calls (mdbm.c _doprnt()), and sometimes in zend_make_printable_zval().  This would seem symptomatic of corrupted memory earlier in the function sequence.  Would this be feasible?  I'm getting a lot of cores, they don't seem to be very stable.  Here's another trace

(gdb) bt
#0  _doprnt () at mdbm.c:1164
#1  0x0fa3b1bc in sprintf () at aio.c:844
#2  0x100862ac in _convert_to_string ()
#3  0x10072ca0 in zend_make_printable_zval ()
#4  0x1008a974 in concat_function ()
#5  0x1010abf8 in execute ()
#6  0x1010de64 in execute ()
#7  0x10110188 in execute ()
#8  0x1010de64 in execute ()
#9  0x10110188 in execute ()
#10 0x10110188 in execute ()
#11 0x1007484c in zend_execute_scripts ()
#12 0x100654c0 in php_execute_script ()
#13 0x10107624 in apache_php_module_main ()
Cannot access memory at address 0x7fff2a54

Do you get these crashes with exactly ONE script?
Are you sure your machine's memory isn't faulty here?

Also, how did you configure PHP? 

I'm actually trying to use two different pre-made (fairly widely used) webmail PHP systems.  I get similar problems working with both TWIG and BasiliX, which is the only reason I suspect it to be IMAP related.  I'm fairly certain it's not the memory in the system, it's an SGI Challenge L, using ECC parity PROM controlled memory, which is very sensitive to errors.  I haven't seen any faults on the system which would indicate a memory problem, and I run a considerable amount of other PHP which doesn't have any problems.

:#0  _doprnt () at mdbm.c:1164
:#1  0x0fa3b1bc in sprintf () at aio.c:844
:#2  0x100862ac in _convert_to_string ()

That tells us the program bombed out while trying to construct a formatted string. This could happen if you are passing a zero in as the parameter corresponding to a format which is expecting a pointer. In other words, you've likely attempted to pass a null pointer to something that's expecting a string.

PHP Version 4.2.1



              System
                               IRIX64 challenger 6.5 04101931 IP25
              Build Date
                               Jun 12 2002 05:43:21
              Configure Command
                               './configure' '--with-mysql=/usr/local/mysql' '--with-apache=../apache_1.3.24'
                               '--with-imap=/usr/local'
              Server API
                               Apache
              Virtual Directory Support
                               disabled
              Configuration File (php.ini)
              Path
                               /usr/local/lib/php.ini
              Debug Build
                               no
              Thread Safety
                               disabled

So it's the imap extension..now, what we need to try and 
fix this are the following things:

1. a short but complete example script which causes this
2. Better GDB backtrace. (you need to configure PHP with --enable-debug )
3. Try the latest NON-stable CVS snapshot from http://snaps.php.net as well as the latest c-client.

--Jani

I just recompiled with --enable-debug, i'm having a hard time reproducing it now.  I did update to the latest c-client devel snap and recompiled php/apache to reflect, with no changes.  I'm attempting to isolate script which causes this 100%, but due to the nature i'm having a hard time.  It also doesn't seem to be coring with php in --enable-debug, does this over-allocate pointers?

Do I also need to recompile apache with debugging options, as I'm using static modules?  I'm afraid i'm not familiar with adding the PHP symbols in this fashion.  After compiling PHP in debug I still get no symbols.

#0  0x1011195c in execute ()
#1  0x10110188 in execute ()
#2  0x10110188 in execute ()
#3  0x10110188 in execute ()
#4  0x1007484c in zend_execute_scripts ()
#5  0x100654c0 in php_execute_script ()
#6  0x10107624 in apache_php_module_main ()
Cannot access memory at address 0x7fff2a24
(no debugging symbols found)...
Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib32/libcrypt.so...done.
Reading symbols from /usr/lib32/libm.so...done.
Reading symbols from /usr/lib32/libdl.so...done.
Reading symbols from /usr/lib32/libsocket.so...done.
Reading symbols from /usr/freeware/lib32/libssl.so...done.
Reading symbols from /usr/freeware/lib32/libcrypto.so...done.
Reading symbols from /usr/lib32/libc.so.1...done.
#0  0x1011195c in execute ()

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

the above should have information where to find more information..(okay, I'm lazy :)

Ok, finally got a good one I think, there's a 0x0 ptr in zif_imap_lsub, i'm not sure if that's normal or not, but I wouldn't think a null pointer ever is. There's definitely a problem somewhere in memory allocation/reference here, you would know better than I if this is definitely in imap's c-client or the php imap module.

(gdb) bt
#0  0x10286034 in imap_valid (name=Cannot access memory at address 0x7ffe3d34
) at imap4r1.c:113
#1  0x10286590 in imap_list_work (stream=0x0, cmd=0x0, ref=0x7ffe4f68 "", 
    pat=0x1030ddd9 "|l", contents=0x0) at imap4r1.c:280
#2  0x102863fc in imap_lsub (stream=0x10494ac0, ref=0x0, pat=0x0)
    at imap4r1.c:248
#3  0x10262494 in mail_lsub (stream=0x101b11b4, 
    ref=0xa <Address 0xa out of bounds>, pat=0x1 <Address 0x1 out of bounds>)
    at mail.c:754
#4  0x101b14d4 in zif_imap_lsub (ht=3, return_value=0x104d4c50, this_ptr=0x0, 
    return_value_used=1) at php_imap.c:1706
#5  0x101193a0 in execute (op_array=0x1053c220) at zend_execute.c:1598
#6  0x10119608 in execute (op_array=0x104ca0f8) at zend_execute.c:1638
#7  0x10119608 in execute (op_array=0x106921e8) at zend_execute.c:1638
#8  0x10119608 in execute (op_array=0x104cd3f0) at zend_execute.c:1638
#9  0x1011bc14 in execute (op_array=0x105192d8) at zend_execute.c:2141
#10 0x1011bc14 in execute (op_array=0x105532c8) at zend_execute.c:2141
#11 0x10077368 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at zend.c:810
#12 0x10065934 in php_execute_script (primary_file=0x7fff28f8) at main.c:1381
#13 0x101128ac in apache_php_module_main (r=0x10462cc8, display_source_mode=0)
    at sapi_apache.c:90
Cannot access memory at address 0x7fff2a24

I can not reproduce this..are you able to reproduce this with some specific script?

It does look like some problem in c-client still.
Are you sure the imap server is not dying there?
Can you access it's logs?

That imap_list_work() line looks a bit odd, this is what I got when I debugged this:

imap_list_work (stream=0x84a77c0, cmd=0x838bf34 "LSUB",  ref=0x84a2734 "{mail.kolumbus.fi:143}", pat=0x84a8434 "*", contents=0x0)

And did you get that backtrace with the latest CVS snapshot of PHP? This one:

http://snaps.php.net/php4-latest.tar.gz

No feedback was provided for this bug for over a month, 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".

Debian Woody Current
Now.... this bug DOES appear in php4.2.1...havent tested it in  other version because it appears in a production deployment of phpgroupware.
This will not show in squirrelmail since it (very smartly) does not trust php-imap.
The bug ONLY presents itself with heavy load, im talking 1,000,000<hits<100,000 (which is what im testing against).
Ive played it with athlon machines, intel pproIV machines, have seen it in production and have only be able to reproduce it with batch tests (400 concurrent users, which mimics my production environment) using eliza scripts.

The result is hung apache proceses that take up 100% of tyhe available cpu. 

I can divide this bug in two parts:
1.- php-imap logs an error to apache and says something about having hit its limit. I have never seen this in production, only in the lab tests.

2.- No error, no logs, no nothing....apache just goes away and away.

This is a critical bug....:(... hard to reproduce but important for bigger sites, DONT overlook it please.