This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 87994

Summary: GLIBC v2.3.2-4.80 crashes apache 1.3.27
Product: [Retired] Red Hat Linux Reporter: Michael McLagan <mmclagan>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: high    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-11-05 13:41:06 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Michael McLagan 2003-04-04 08:54:43 EST
Description of problem:

Server crashes during startup when mod_perl loads DBD::mysql.  When not loading
this DBD, server crashes when mod_status url is invoked.

Version-Release number of selected component (if applicable):

2.3.2-4.80

How reproducible:

Every time

Steps to Reproduce:
1. Compile apache 1.3.27
2. Compile mod_perl 1.27
3. Configure a <Perl> section to "use DBI;use DBD::mysql;"
4. Start server
    
Actual results:

SIGSEGV!  :(

(gdb) run -X
Starting program: /usr/sbin/httpd -X
(no debugging symbols found)...[New Thread 16384 (LWP 26269)]
(no debugging symbols found)...

(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 26269)]
0x40007713 in do_lookup_versioned () from /lib/ld-linux.so.2
(gdb) 
(gdb) bt
#0  0x40007713 in do_lookup_versioned () from /lib/ld-linux.so.2
#1  0x40006aaf in _dl_lookup_versioned_symbol_internal ()
   from /lib/ld-linux.so.2
#2  0x40009ed1 in fixup () from /lib/ld-linux.so.2
#3  0x40009dc0 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#4  0x40278a3d in gethostbyaddr_r@@GLIBC_2.1.2 () from /lib/libc.so.6
#5  0x40278882 in gethostbyaddr () from /lib/libc.so.6
#6  0x0805811d in ap_get_remote_host ()
#7  0x403e5132 in find_allowdeny () from /usr/lib/apache/mod_access.so
#8  0x403e52b9 in check_dir_access () from /usr/lib/apache/mod_access.so
#9  0x08054b7c in run_method ()
#10 0x08054c21 in ap_check_access ()
#11 0x080698bd in process_request_internal ()
#12 0x08069aeb in ap_process_request ()
#13 0x08061738 in child_main ()
#14 0x08061a25 in make_child ()
#15 0x08061abd in startup_children ()
#16 0x0806262b in standalone_main ()
#17 0x080629c0 in main ()
#18 0x401a44ad in __libc_start_main () from /lib/libc.so.6

When not loading the DBD::mysql module, the server crashes when accessing the
status handler:

<Location /stats>
   SetHandler server-status
   order allow,deny
   allow from .invlogic.com
</Location>

#0  0x400076ce in do_lookup_versioned () from /lib/ld-linux.so.2
#1  0x40006aaf in _dl_lookup_versioned_symbol_internal ()
   from /lib/ld-linux.so.2
#2  0x40009ed1 in fixup () from /lib/ld-linux.so.2
#3  0x40009dc0 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#4  0x40278a3d in gethostbyaddr_r@@GLIBC_2.1.2 () from /lib/libc.so.6
#5  0x40278882 in gethostbyaddr () from /lib/libc.so.6
#6  0x0805811d in ap_get_remote_host ()
#7  0x403e5132 in find_allowdeny () from /usr/lib/apache/mod_access.so
#8  0x403e52b9 in check_dir_access () from /usr/lib/apache/mod_access.so
#9  0x08054b7c in run_method ()
#10 0x08054c21 in ap_check_access ()
#11 0x080698bd in process_request_internal ()
#12 0x08069aeb in ap_process_request ()
#13 0x08061738 in child_main ()
#14 0x08061a25 in make_child ()
#15 0x08061abd in startup_children ()
#16 0x0806262b in standalone_main ()
#17 0x080629c0 in main ()
#18 0x401a44ad in __libc_start_main () from /lib/libc.so.6

As long as the /stats location uses "allow from 198.182.196.", the crashes with
the server stop.

Expected results:

Not crashing would be nice!

Additional info:
Comment 1 Jakub Jelinek 2003-04-04 11:00:34 EST
Can you try ftp://people.redhat.com/jakub/glibc/errata/8.0/
? There were a couple of bugs in the errata which will be updated soon.
Comment 2 Michael McLagan 2003-04-04 13:03:17 EST
I retrieved the mentioned files.  Upon installing them on a test system, I
received the same error with the same basic backtrace as shown previously.
Comment 3 Michael McLagan 2003-04-12 12:23:41 EDT
I updated to 2.3.2-4.80.6 and the crashes continue.  After pulling out our
collective hair for several days, we went back to the distributed glibc,
2.2.93-5 and the segfaults stopped.  Something between these two packages causes
our apache daemon to segfault somewhat reliably although I can't quite determine
where.

[Sat Apr 12 10:57:32 2003] [notice] child pid 26704 exit signal Segmentation
fault (11)
[Sat Apr 12 10:57:33 2003] [notice] child pid 7819 exit signal Segmentation
fault (11)
[Sat Apr 12 10:57:33 2003] [notice] child pid 26686 exit signal Segmentation
fault (11)
[Sat Apr 12 10:57:34 2003] [notice] child pid 26723 exit signal Segmentation
fault (11)
[Sat Apr 12 10:57:34 2003] [notice] child pid 26710 exit signal Segmentation
fault (11)
[Sat Apr 12 11:01:13 2003] [notice] child pid 5495 exit signal Segmentation
fault (11)
[Sat Apr 12 11:03:25 2003] [notice] child pid 9471 exit signal Segmentation
fault (11)
[Sat Apr 12 11:17:15 2003] [notice] child pid 26719 exit signal Segmentation
fault (11)
[Sat Apr 12 11:18:18 2003] [notice] child pid 26727 exit signal Segmentation
fault (11)
[Sat Apr 12 11:22:55 2003] [notice] child pid 26722 exit signal Segmentation
fault (11)
[Sat Apr 12 11:25:07 2003] [notice] child pid 26726 exit signal Segmentation
fault (11)

They started on 4/3 when I updated openssl based on the CERT, which updated
glibc at the same time.  (I don't remember what previous rev we had, but my 
logs don't show any glibc retrieved since 28-Nov-02.

Note this is in addition to the faults being seen due to DNS resolution issues.
Comment 4 Ulrich Drepper 2003-10-03 04:47:41 EDT
If you still see this, what does starting the program with

  LD_DEBUG=all LD_DEBUG_OUTPUT=/tmp/some-file

Attach the content of /tmp/some-file.  This will show what symbol is looked up.
Comment 5 Ulrich Drepper 2003-11-05 13:41:06 EST
No response in a month.  If this is a valid problem which still exists
reopen.