bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.1.96 & apache mod_setenv


From: Petr Vandrovec
Subject: Re: 2.1.96 & apache mod_setenv
Date: Wed, 1 Nov 2000 21:19:53 MET-1

Hi,
  does anybody around have some idea why code which worked with all
previous glibc releases (2.1.3, 2.1.94, 2.1.95) fails with 2.1.96 
in strange ways? I tried to load efence to no avail, but results are 
still same: when loaded with 2.1.96 libc, apache dies. When loaded 
with 2.1.95 libc by 2.1.96 loader, it exits with 'error 1', probably 
because of some problem with relocations (?!). Only loading by 2.1.95 
loader with 2.1.95 libc works.
  I even recompiled app (apache + php) against 2.1.96, but behavior 
is still same: sigsegv.
  Also, when I start app from gdb, in stacktrace (see at the end)
there is 
#0 0x401298b9 in malloc () from /lib/libc.so.6
  When loading core generated by previous run, it is
#0 0x401298b9 in ?? ()
although other (php, apache) symbols are correctly resolved
(last __libc_start_main is also unresolved)
                                    Thanks,
                                        Petr Vandrovec
                                        address@hidden
                                        
------- Forwarded Message Follows -------

From:           address@hidden
To:             Ben Collins <address@hidden>
Subject:        Re: 2.1.96 & apache mod_setenv
Date sent:      Wed, 1 Nov 2000 21:11:22 MET-1

On  1 Nov 00 at 7:36, Ben Collins wrote:
> On Wed, Nov 01, 2000 at 12:26:57PM +0000, Petr Vandrovec wrote:
> > Hi,
> >   I had compiled apache with glibc2.1.94. It worked with 2.1.95, but
> > when I include this module into apache with glibc2.1.96, I get SIGSEGV.
> > It happens either in dl_close, or in malloc (in dl_close if I do
> > LD_PRELOAD=/usr/lib/libefence.so.0). Should I try to find what's wrong
> > in my mod_setenv, or is it known problem (I did not found mentioned
> > it in bugreport database, but maybe...) ?
> 
> My first guess would be your module. Have you tried recompiling it?

Bad news... I recompiled everything from scratch (upgraded
apache 1.3.12 -> 1.3.14 and php 4.0.2 -> 4.0.3pl1), and only change 
is that now it dies in php (before recompilation it worked after
disabling mod_setenvif... disabling php is not an option). It works 
as follow (2.1.96 installed...):

vana# bin/httpd -X -DSSL; echo $?
Segmentation fault
139
vana# /lib/ld-2.1.95.so bin/httpd -X -DSSL; echo $?
1
<< in log there is that "Order" (from "Order allow,deny") is not
   known apache option ?! >>
vana# LD_PRELOAD="/lib/libc-2.1.95.so" bin/httpd -X -DSSL; echo $?
Segmentation fault
139
vana# LD_PRELOAD="/lib/libc-2.1.95.so" /lib/ld-2.1.95.so bin/httpd -X -DSSL; 
echo $?
<< apache running... voila... >>

So I must have both loader and libc from 2.1.95. I recompiled apache,
php and all my modules against 2.1.96. I did not recompile other system
libraries, such as gdbm, openssl and so on. Efence did not found any
troubles with apache/php, even on long runs (I was running apache
with libefence for a while few weeks ago due to tracking down problems 
in kerberos).

When running through system log, I also found that "pserver" from "ncpfs"
package was killed by SIGSEGV. It did not ever happen in the past.

vana:/usr/local/apache# LD_PRELOAD="/lib/libc-2.1.95.so" /lib/ld-2.1.95.so 
--list bin/httpd
        /lib/libc-2.1.95.so => /lib/libc-2.1.95.so (0x40001000)
        libm.so.6 => /lib/libm.so.6 (0x40112000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4012f000)
        libgdbm.so.1 => /usr/lib/libgdbm.so.1 (0x4015c000)
        libdb2.so.2 => /usr/lib/libdb2.so.2 (0x40162000)
        libdl.so.2 => /lib/libdl.so.2 (0x401a7000)
        /lib/ld-linux.so.2 => /lib/ld-2.1.95.so (0x2aaaa000)
vana:/usr/local/apache# LD_PRELOAD="/lib/libc-2.1.95.so" /lib/ld-2.1.96.so 
--list bin/httpd
        /lib/libc-2.1.95.so => /lib/libc-2.1.95.so (0x40000000)
        libm.so.6 => /lib/libm.so.6 (0x40111000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4012e000)
        libgdbm.so.1 => /usr/lib/libgdbm.so.1 (0x4015b000)
        libdb2.so.2 => /usr/lib/libdb2.so.2 (0x40161000)
        libdl.so.2 => /lib/libdl.so.2 (0x401a6000)
        /lib/ld-linux.so.2 => /lib/ld-2.1.96.so (0x2aaaa000)
vana:/usr/local/apache# LD_PRELOAD="/lib/libc-2.1.96.so" /lib/ld-2.1.95.so 
--list bin/httpd
        /lib/libc-2.1.96.so => /lib/libc-2.1.96.so (0x40001000)
        libm.so.6 => /lib/libm.so.6 (0x40113000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40130000)
        libgdbm.so.1 => /usr/lib/libgdbm.so.1 (0x4015d000)
        libdb2.so.2 => /usr/lib/libdb2.so.2 (0x40163000)
        libdl.so.2 => /lib/libdl.so.2 (0x401a8000)
        /lib/ld-linux.so.2 => /lib/ld-2.1.95.so (0x2aaaa000)
vana:/usr/local/apache# LD_PRELOAD="/lib/libc-2.1.96.so" /lib/ld-2.1.96.so 
--list bin/httpd
        /lib/libc-2.1.96.so => /lib/libc-2.1.96.so (0x40000000)
        libm.so.6 => /lib/libm.so.6 (0x40112000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4012f000)
        libgdbm.so.1 => /usr/lib/libgdbm.so.1 (0x4015c000)
        libdb2.so.2 => /usr/lib/libdb2.so.2 (0x40162000)
        libdl.so.2 => /lib/libdl.so.2 (0x401a7000)
        /lib/ld-linux.so.2 => /lib/ld-2.1.96.so (0x2aaaa000)

gdb bin/httpd; set args -X -DSSL; run:

Program received signal SIGSEGV, Segmentation fault.
0x401298b9 in malloc () from /lib/libc.so.6
(gdb) bt
#0  0x401298b9 in malloc () from /lib/libc.so.6
#1  0x40129714 in malloc () from /lib/libc.so.6
#2  0x808404d in regcomp ()
#3  0x805a80e in ap_pregcomp ()
#4  0x80626b3 in filesection ()
#5  0x805ddec in invoke_cmd ()
#6  0x805e951 in ap_handle_command ()
#7  0x805e9ef in ap_srm_command_loop ()
#8  0x8062caf in virtualhost_section ()
#9  0x805ddec in invoke_cmd ()
#10 0x805e951 in ap_handle_command ()
#11 0x805e9ef in ap_srm_command_loop ()
#12 0x805f0b9 in ap_process_resource_config ()
#13 0x805fa3c in ap_read_config ()
#14 0x8069c80 in standalone_main ()
#15 0x806a5cc in main ()
#16 0x400d6bcc in __libc_start_main () from /lib/libc.so.6

Perhaps loading libc at 0x40000000 instead of 0x40001000 by new
loader brokes something?

                            Thanks,
                                    Petr Vandrovec
                                    address@hidden
                                    



reply via email to

[Prev in Thread] Current Thread [Next in Thread]