Bug #17724 Updated: php4/imap functions causing apache cores at random

ID: 17724 Updated by: si@darkness.nu Reported By: si@darkness.nu -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: IRIX 6.5.16F / IP25 PHP Version: 4.2.1 New Comment: 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? Previous Comments: ------------------------------------------------------------------------ [2002-06-13 08:36:52] sniper@php.net 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 ------------------------------------------------------------------------ [2002-06-12 23:54:29] si@darkness.nu 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 ------------------------------------------------------------------------ [2002-06-12 09:20:30] sniper@php.net Also, how did you configure PHP? ------------------------------------------------------------------------ [2002-06-12 09:19:56] sniper@php.net Do you get these crashes with exactly ONE script? Are you sure your machine's memory isn't faulty here? ------------------------------------------------------------------------ [2002-06-12 09:17:33] si@darkness.nu 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 ------------------------------------------------------------------------ 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/17724 -- Edit this bug report at http://bugs.php.net/?id=17724&edit=1