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

Re: Bug #620550

>>> On 4/7/2011 at  1:24 AM, in message <[🔎] 20110407052431.GD10067@ktnx.net>, Damyan
Ivanov <dmn@debian.org> wrote: 
>[Please excuse the CC in case you are subscribed to debian-perl]
>-=| Keith Lawson, Wed, Apr 06, 2011 at 03:39:19PM -0400 |=-
>> I recently opened bug #620550 under libapache2-mod-perl2 and had the 
>> bug reassigned to libapache2-mod-php5 when I discovered that 
>> removing mod_php5 fixed the problem. I've spent a lot of time 
>> troubleshooting the issue and I can't nail down exactly how PHP is 
>> affecting mod_perl ties. I though I'd look here for some advice on 
>> providing more details about my problem or to see if any of the 
>> Debian Perl community has experienced similar issues?
>> Basic summary is ties using GDBM_File do not work for me when the 
>> Debian mod_php5 library is installed. Removing the Debian package 
>> for PHP or installing my own version of libphp5.so fixes the 
>> mod_perl problem. I can't imagine for the life of me how the PHP 
>> library is breaking Perl. Any suggestions? 
> There was a suggestion from PHP maintainers that this could be caused 
> by two modules being compiled against different versions of Berkeley 
> DB library.
> What you can try to confirm this is to rebuild libapache2-mod-perl2, 
> test, then if the problem persists, rebuild libapache2-php5 and test 
> again.

I think there's some confusion here between GNU DB (libgdbm.so) and Berkely DB (libdb.so), I'm using
 libdgbm.so from Perl, not libdb.so. libphp5.so isn't linked against "libdgbm.so" at all because it's build with
 the flag "--without-gdbm": 

ldd /usr/lib/apache2/modules/libphp5.so
        linux-gate.so.1 =>  (0xb7713000)
        libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb6f72000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb6f5e000)
        libonig.so.2 => /usr/lib/libonig.so.2 (0xb6f17000)
        libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb6ecd000)
        libdb-4.8.so => /usr/lib/libdb-4.8.so (0xb6d67000)
        libqdbm.so.14 => /usr/lib/libqdbm.so.14 (0xb6d1d000)
        libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb6d0c000)
        libpcre.so.3 => /lib/libpcre.so.3 (0xb6cd9000)
        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6cb2000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6cae000)
        libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb6c97000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb6c68000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb6bb6000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb6b92000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb6b8f000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb6a65000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb691f000)
        libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb67c7000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb67ad000)
        /lib/ld-linux.so.2 (0xb7714000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb67a6000)
        libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb67a3000)
        libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb678f000)

However I did so some more poking around and found that the Perl *Berkely* DB is linked against a different version of libdb: 

ldd /usr/lib/perl/5.10/auto/DB_File/DB_File.so
        linux-gate.so.1 =>  (0xb77bd000)
        libdb-4.7.so => /usr/lib/libdb-4.7.so (0xb764d000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7507000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb74ed000)

I compiled DB_File.so from the CPAN source so it linked to  /usr/lib/libdb-4.8.so and as expected that didn't fix the issue. 

mod_perl.so isn't linked to either DB library so I didn't bother compiling it from source: 

ldd /usr/lib/apache2/modules/mod_perl.so 
        linux-gate.so.1 =>  (0xb7755000)
        libperl.so.5.10 => /usr/lib/libperl.so.5.10 (0xb75ca000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb75c6000)
        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb759f000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7586000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7440000)
        libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb740e000)
        /lib/ld-linux.so.2 (0xb7756000)

Looking at my notworking.strace above you can see that /usr/lib/libdb-4.8.so is loaded but  /usr/lib/libdb-4.7.so never is. Perl loads /usr/lib/libgdbm.so.3 (GNU DB) here: 

14043 open("/usr/lib/perl/5.10/auto/GDBM_File/GDBM_File.so", O_RDONLY) = 13
14043 read(13, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\30\0\0004\0\0\0"..., 512) = 512
14043 fstat64(13, {st_mode=S_IFREG|0644, st_size=40856, ...}) = 0
14043 mmap2(NULL, 43692, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 13, 0) = 0xb6429000
14043 mmap2(0xb6433000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 13, 0x9) = 0xb6433000
14043 close(13)                         = 0
14043 open("/etc/ld.so.cache", O_RDONLY) = 13
14043 fstat64(13, {st_mode=S_IFREG|0644, st_size=20934, ...}) = 0
14043 mmap2(NULL, 20934, PROT_READ, MAP_PRIVATE, 13, 0) = 0xb6423000
14043 close(13)                         = 0
14043 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
14043 open("/usr/lib/libgdbm.so.3", O_RDONLY) = 13



The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in  reliance upon, this information by persons or entities other  than the intended recipient is prohibited. If you received this  in error, please contact the sender and delete the material from any computer. 

Reply to: