Bug 87994
| Summary: | GLIBC v2.3.2-4.80 crashes apache 1.3.27 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Michael McLagan <mmclagan> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.0 | CC: | fweimer |
| 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 18:41:06 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. 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. 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. No response in a month. If this is a valid problem which still exists reopen. |
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: