php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #17724 php4/imap functions causing apache cores at random
Submitted: 2002-06-12 06:13 UTC Modified: 2002-07-27 01:00 UTC
Votes:4
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:1 (33.3%)
From: si at darkness dot nu Assigned:
Status: No Feedback Package: IMAP related
PHP Version: 4.2.1 OS: IRIX 6.5.16F / IP25
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
11 - 11 = ?
Subscribe to this entry?

 
 [2002-06-12 06:13 UTC] si at darkness dot nu
Appears to be possibly memory corruption in imap functions under php4.2.1?  Compiled using imap-2001a.

This GDB was configured as "mips-sgi-irix6.5"...
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  0x1021be74 in imap_valid (name=0x105e9570 "{localhost:143}")
    at imap4r1.c:113
113     {
(gdb) bt
#0  0x1021be74 in imap_valid (name=0x105e9570 "{localhost:143}")
    at imap4r1.c:113
#1  0x1021c4c8 in imap_list_work (stream=0x105eaae8, cmd=0x102eedc0 "LSUB", 
    ref=0x105e9570 "{localhost:143}", pat=0x105614c0 "*", contents=0x0)
    at imap4r1.c:280
#2  0x1021c328 in imap_lsub (stream=0x105eaae8, 
    ref=0x105e9570 "{localhost:143}", pat=0x105614c0 "*") at imap4r1.c:248
#3  0x101f5458 in mail_lsub (stream=0x105eaae8, 
    ref=0x105e9570 "{localhost:143}", pat=0x105614c0 "*") at mail.c:754
#4  0x10148400 in zif_imap_lsub (ht=3, return_value=0x105e92c8, 
    this_ptr=0x105e9570, return_value_used=274076864) at php_imap.c:1706
#5  0x100e2eb8 in execute (op_array=0x105557c8) at zend_execute.c:1598
#6  0x100e3100 in execute (op_array=0x10457c90) at zend_execute.c:1638
#7  0x100e3100 in execute (op_array=0x105952b0) at zend_execute.c:1638
#8  0x100e3100 in execute (op_array=0x105d7d50) at zend_execute.c:1638
#9  0x100e5424 in execute (op_array=0x1052b3e0) at zend_execute.c:2141
#10 0x100e5424 in execute (op_array=0x104d5c80) at zend_execute.c:2141
#11 0x100700a0 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at zend.c:810
#12 0x10064e44 in php_execute_script (primary_file=0x7fff2970) at main.c:1381
#13 0x100dcec4 in apache_php_module_main (r=0x7fff2970, 
    display_source_mode=2147428744) at sapi_apache.c:90
#14 0x10061370 in php_restore_umask ()


This GDB was configured as "mips-sgi-irix6.5"...
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  0x1021c284 in imap_list (stream=0x104f74d8, ref=0x1021c280 "'?????", 
    pat=0x104e2507 "/%") at imap4r1.c:232
232     {
(gdb) bt
#0  0x1021c284 in imap_list (stream=0x104f74d8, ref=0x1021c280 "'?????", 
    pat=0x104e2507 "/%") at imap4r1.c:232
#1  0x101f5228 in mail_list (stream=0x104f74d8, 
    ref=0x104b5500 "{mail.darkness.nu:143}", pat=0x104e2500 "BasiliX/%")
    at mail.c:721
#2  0x10146af4 in zif_imap_list_full (ht=3, return_value=0x104e24b0, 
    this_ptr=0x104e2500, return_value_used=273556743) at php_imap.c:1420
#3  0x100e2eb8 in execute (op_array=0x1043b5d0) at zend_execute.c:1598
#4  0x100e3100 in execute (op_array=0x1041c530) at zend_execute.c:1638
#5  0x100e3100 in execute (op_array=0x104aedd0) at zend_execute.c:1638
#6  0x100e3100 in execute (op_array=0x104a02b0) at zend_execute.c:1638
#7  0x100e5424 in execute (op_array=0x10468f78) at zend_execute.c:2141
#8  0x100700a0 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at zend.c:810
#9  0x10064e44 in php_execute_script (primary_file=0x7fff2930) at main.c:1381
#10 0x100dcec4 in apache_php_module_main (r=0x7fff2930, 
    display_source_mode=2147428680) at sapi_apache.c:90
#11 0x10061370 in php_restore_umask ()

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-12 09:07 UTC] sniper@php.net
Not a bug in PHP but in the c-client. Please report this 
to the c-client authors.

 [2002-06-12 09:17 UTC] si at darkness dot 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
 [2002-06-12 09:19 UTC] 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:20 UTC] sniper@php.net
Also, how did you configure PHP? 
 [2002-06-12 23:54 UTC] si at darkness dot 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-13 08:36 UTC] 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-13 19:30 UTC] si at darkness dot nu
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?
 [2002-06-13 19:59 UTC] si at darkness dot nu
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 ()
 [2002-06-13 20:32 UTC] sniper@php.net
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 :)

 [2002-06-16 05:00 UTC] si at darkness dot nu
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
 [2002-06-26 20:49 UTC] sniper@php.net
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)




 [2002-06-26 20:51 UTC] sniper@php.net
And did you get that backtrace with the latest CVS snapshot of PHP? This one:

http://snaps.php.net/php4-latest.tar.gz
 [2002-07-27 01:00 UTC] php-bugs at lists dot php dot net
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".
 [2003-01-30 00:10 UTC] alex at sogrp dot com
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.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sun Sep 20 02:01:25 2020 UTC