PHP :: Bug #1494 :: Apache segfaults consistently

Bug #1494	Apache segfaults consistently
Submitted:	1999-06-04 14:43 UTC	Modified:	1999-06-18 11:54 UTC
From:	athompso at commerced dot com	Assigned:
Status:	Closed	Package:	Reproducible Crash
PHP Version:	3.0.9	OS:	RH6.0 & OpenBSD 2.4
Private report:	No	CVE-ID:	None

View Add Comment Developer Edit

Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.

php.net Username: php.net Password:

Quick Fix:	(description)
	Block user comment
Status:		Assign to:
Package:
Bug Type:
Summary:
From:	athompso at commerced dot com
New email:
PHP Version:		OS:

New/Additional Comment:

[1999-06-04 14:43 UTC] athompso at commerced dot com

Attempting to use the "Reload MySQL" feature of phpMyAdmin;
httpd dies with a segfault every time.  Also dies frequently elsewhere inside phpMyAdmin.  Too scared to try any other code :-)

(Re)Built MySQL, apache, mod_php3 from SRPMs, added "-g" for Apache and mod_php3; 

Here's what gdb (ever useful... *sigh*) tells me:
[root@triton SPECS]# gdb /usr/sbin/httpd
GNU gdb 4.17.0.11 with Linux support
[...chop...]
This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)...
(gdb) run -X   
Starting program: /usr/sbin/httpd -X
Cannot access memory at address 0x696b735f.
(gdb) 

The "cannot access memory" error comes *immediately* after I try to access
http://triton.commerced.com/phpMyAdmin/main.php3?server=1&mode=reload

and this is reproducible.

I can't get httpd to leave a core file if my life depended on it.  Doesn't matter what user I run as, doesn't matter where CoreFileDirectory is pointing to... 

any hints appreciated.

Oooops.  Re-ran this under gdb, but this time I remembered to use the "bt" command - I'm used to another debugger that does stack traces for me automatically :)

(gdb) bt
#0  _dl_debug_state () at dl-debug.c:56
#1  0x4000a12b in _dl_catch_error (errstring=0xbfffda30, 
    operate=0x401797a0 <dl_open_worker>, args=0xbfffda34) at dl-error.c:141
#2  0x401799fd in _dl_open (file=0x80852e4 "/etc/httpd/modules/libperl.so", mode=258)
    at dl-open.c:176
#3  0x4009e058 in dlopen_doit (a=0xbfffdb3c) at dlopen.c:39
#4  0x4000a12b in _dl_catch_error (errstring=0x4009fd00, 
    operate=0x4009e030 <dlopen_doit>, args=0xbfffdb3c) at dl-error.c:141
#5  0x4009e608 in _dlerror_run (operate=0x4009e030 <dlopen_doit>, args=0xbfffdb3c)
    at dlerror.c:122
#6  0x4009e01d in __dlopen_check (file=0x80852e4 "/etc/httpd/modules/libperl.so", 
    mode=258) at dlopen.c:50
#7  0x806e411 in ap_os_dso_load ()
#8  0x804e6c8 in ap_get_server_built ()
#9  0x8053e0e in ap_clear_module_list ()
#10 0x80546b3 in ap_handle_command ()
#11 0x8054744 in ap_srm_command_loop ()
#12 0x8054b50 in ap_process_resource_config ()
#13 0x8055412 in ap_read_config ()
#14 0x805e9c1 in ap_child_terminate ()
#15 0x805f203 in main ()
#16 0x400b8cb3 in __libc_start_main (main=0x805eedc <main>, argc=2, argv=0xbffffd84, 
    init=0x804dbfc <_init>, fini=0x8071f1c <_fini>, rtld_fini=0x4000a350 <_dl_fini>, 
---Type <return> to continue, or q <return> to quit---
    stack_end=0xbffffd7c) at ../sysdeps/generic/libc-start.c:78
(gdb) 

Now, this is really, really weird.  I have absolutely no idea why it feels the need to load perl at this precise moment in time...

(I'm going to exceed the POST buffersize in a minute here...)

After I *removed* mod_perl from my apache config, the same exercise leads to:
(gdb) run -X
Starting program: /usr/sbin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x400f9634 in chunk_free (ar_ptr=0x40189580, p=0x80e1010) at malloc.c:3009
malloc.c:3009: No such file or directory.
(gdb) bt
#0  0x400f9634 in chunk_free (ar_ptr=0x40189580, p=0x80e1010) at malloc.c:3009
#1  0x400f9505 in __libc_free (mem=0x80e1018) at malloc.c:2932
#2  0x401ef232 in _efree ()
#3  0x401ed38b in pval_destructor ()
#4  0x401edb6f in tc_destroy ()
#5  0x401edbc3 in tcm_destroy ()
#6  0x401e6f8b in php3_request_shutdown ()
#7  0x805038e in ap_run_cleanup ()
#8  0x804ebbd in ap_clear_pool ()
#9  0x804ec31 in ap_destroy_pool ()
#10 0x804ebac in ap_clear_pool ()
#11 0x805ddaf in ap_child_terminate ()
#12 0x805e31c in ap_child_terminate ()
#13 0x805e479 in ap_child_terminate ()
#14 0x805ea96 in ap_child_terminate ()
#15 0x805f203 in main ()
#16 0x400b8cb3 in __libc_start_main (main=0x805eedc <main>, argc=2, argv=0xbffffd84, 
    init=0x804dbfc <_init>, fini=0x8071f1c <_fini>, rtld_fini=0x4000a350 <_dl_fini>, 
    stack_end=0xbffffd7c) at ../sysdeps/generic/libc-start.c:78
(gdb)

Versions:  (all rebuilt from SRPM)
 apache-1.3.6-8 (SPEC file modified to add "-g")
 mod_php3-3.0.8-1 (SPEC file modified to add "-g")
 MySQL-3.22.22-1 (pristine, I think...)
 glibc-2.1.1-6

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports

[1999-06-04 19:50 UTC] athompso at commerced dot com

Aaaargh.  I removed the RPMs, and grabbed the PHP and Apache tarballs (3.0.8, 1.3.6 respectively) and built httpd from scratch.  With "-g", with debugging support turned on, etc...

now, when I access that same page, I get the following in the two log files:
==> /usr/local/apache/logs/access_log <==
userma159.videon.wave.ca - - [04/Jun/1999:19:47:09 -0500] "GET /phpMyAdmin/images/bkg.gif HTTP/1.1" 304 - "http://triton.commerced.com/phpMyAdmin/main.php3?server=1" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; msnca)"
userma159.videon.wave.ca - - [04/Jun/1999:19:47:09 -0500] "GET /phpMyAdmin/images/plus.gif HTTP/1.1" 304 - "http://triton.commerced.com/phpMyAdmin/left.php3?server=1" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; msnca)"
userma159.videon.wave.ca - - [04/Jun/1999:19:47:14 -0500] "GET /phpMyAdmin/main.php3?server=1&mode=reload HTTP/1.1" 200 2750 "http://triton.commerced.com/phpMyAdmin/main.php3?server=1" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; msnca)"

==> /usr/local/apache/logs/error_log <==
sh: /usr/local/php/bin/mysqladmin: No such file or directory
sh: /usr/local/php/bin/mysqladmin: No such file or directory
sh: /usr/local/php/bin/mysqladmin: No such file or directory
---------------------------------------
Block 0x081AAD50 status at variables.c:77:
Beginning:      Overrun (magic=0x08186438, expected=0x7312F8DC)
      End:      Unknown
---------------------------------------

One thing of note is that as far as I can tell, the damn thing is *supposed* to be executing /usr/bin/mysqladmin.
In fact, I added some extra code to the page: 
main.php3 *thinks* it is about to call EscapeShellCmd() on these commands:

/usr/bin/mysqladmin --user=root --password= --host=localhost --port= version
/usr/bin/mysqladmin --user=root --password= --host=localhost --port= proc
/usr/bin/mysqladmin --user=root --password= --host=localhost --port= reload


This is getting ridiculous...  and this means that either something in libmysql* is badly broken (not impossible), or something in the system itself is broken (ie. gcc, libc, etc.).

[1999-06-04 21:17 UTC] athompso at commerced dot com

OK, I got paranoid...
grabbed the MySQL tarball and rebuild it from scratch, too.
Then reconfig'ed/rebuilt PHP and Apache too.

Still dies.
Now the error refers to string.c, instead of "unknown".

[1999-06-04 21:18 UTC] athompso at commerced dot com

...but I did figure out why the path to mysqladmin is wrong: I always configure with --enable-safe-mode, and I forgot to turn it off in .htaccess and httpd.conf.

Still blows up, though...

[1999-06-05 23:00 UTC] athompso at commerced dot com

Grabbed tarballs for MySQL, PHP 3.0.8 and Apache 1.3.6
(ftp'ed the tarballs from the linux box, in fact...)

Reconfigured all, rebuilt all under OpenBSD 2.4

accessing the "Reload MySQL" link in phpMyAdmin produces the following in the error log:

sh: /usr/local/php/bin/mysqladmin: not found
sh: /usr/local/php/bin/mysqladmin: not found
sh: /usr/local/php/bin/mysqladmin: not found
---------------------------------------
Block 0x00189F80 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 27 bytes)
      End:      OK
---------------------------------------
httpd in free(): warning: chunk is already free.


That is the *SAME* spot that it dies under Linux.  
Sorry, guys -- looks like the bug is in PHP 3.0.8, not RedHat's glibc.

[1999-06-05 23:46 UTC] athompso at commerced dot com

The problem is not limited to phpMyAdmin.  
I have an admin page inside one of my web apps -- it does multiple MySQL queries as it displays;
here's a sample from the Apache error_log:

---------------------------------------
httpd in free(): warning: page is already free.
---------------------------------------
Block 0x00151F00 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 29 bytes)
      End:      OK
---------------------------------------
httpd in free(): warning: chunk is already free.
---------------------------------------
Block 0x001528C0 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 29 bytes)
      End:      OK
---------------------------------------
httpd in free(): warning: chunk is already free.
---------------------------------------
Block 0x001528C0 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 29 bytes)
      End:      OK
-----------------------------------------------------------
Block 0x001528C0 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 29 bytes)
      End:      OK
---------------------------------------
httpd in free(): warning: chunk is already free.
---------------------------------------
Block 0x00151F00 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 29 bytes)
      End:      OK
---------------------------------------
httpd in free(): warning: chunk is already free.
---------------------------------------
Block 0x00151F00 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 29 bytes)
      End:      OK
---------------------------------------
---------------------------------------
Block 0x00151F00 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 29 bytes)
      End:      OK
---------------------------------------
httpd in realloc(): warning: chunk is already free.
FATA():  Unable to allocate 37 bytes


Further back, there's also some stuff like:
---------------------------------------
Block 0x00168440 status at php3_hash.c:644:
Beginning:      Cached (allocated on php3_hash.c:187, 5 bytes)
      End:      OK
---------------------------------------
---------------------------------------
Block 0x00168440 status at variables.c:77:
Beginning:      Cached (allocated on php3_hash.c:187, 5 bytes)
      End:      OK
---------------------------------------
---------------------------------------
Block 0x00168440 status at variables.c:77:
Beginning:      Cached (allocated on php3_hash.c:367, 5 bytes)
      End:      OK
---------------------------------------
---------------------------------------
Block 0x00168440 status at variables.c:77:
Beginning:      Cached (allocated on php3_hash.c:367, 5 bytes)
      End:      OK
---------------------------------------
---------------------------------------
Block 0x00168440 status at variables.c:77:
Beginning:     (allocated on php3_hash.c:367, 5 bytes)
      End:      OK
---------------------------------------
httpd in free(): warning: chunk is already free.
httpd in free(): warning: chunk is already free.
---------------------------------------
Block 0x00198580 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 51 bytes)
      End:      OK
---------------------------------------
httpd in free(): warning: chunk is already free.
httpd in free(): warning: chunk is already free.
---------------------------------------
Block 0x00121640 status at variables.c:77:
Beginning:      Cached (allocated on functions/string.c:1272, 19 bytes)
      End:      OK

and...
Block 0x00168080 status at php3_hash.c:644:
Beginning:      Cached (allocated on language-parser.y:658, 5 bytes)
      End:      OK
---------------------------------------
---------------------------------------
Block 0x00168080 status at variables.c:77:
Beginning:      Cached (allocated on php3_hash.c:187, 5 bytes)
      End:      OK
--------------------------

[1999-06-07 19:14 UTC] athompso at commerced dot com

Confirmed that this bug still exists with 3.0.9, at least under RH6.0.
Configured and rebuilt PHP, rebuilt Apache, 
when I click on the "reload MySQL" link, I now see in the error log:
---------------------------------------
Block 0x081A0538 status at variables.c:77:
Beginning:  	Cached (allocated on functions/string.c:1318, 27 bytes)
      End:	OK
---------------------------------------

[1999-06-18 11:54 UTC] sas at cvs dot php dot net

fixed in CVS

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Sun May 19 02:01:35 2024 UTC