496861 - Thunderbird Shredder/3.0b3pre won't launch over remote X11 with libnss-ldap installed

Status: VERIFIED DUPLICATE of bug 292127

(MailNews Core :: Address Book, defect)

Description

[Craig Ringer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090607 Shredder/3.0b3pre

On systems using libnss-ldap (at least Ubuntu 8.10 and Ubuntu 9.04), Shredder/3.0b3pre binaries fail to launch over remote X connections like SSH tunnels, where 2.0.0 launches and runs fine. The `thunderbird' shell script invokes `./run-mozilla.sh ./thunderbird-bin' as expected, and run-mozilla.sh in turn invokes the `thunderbird-bin' binary. However, the binary doesn't get far in startup.

It seems to hang before spawning any threads:

craig:~$ ps -Lf -u craig | grep thunderbird
craig    15888 15246 15888  0    1 15:07 pts/1    00:00:00 /bin/sh ./thunderbird
craig    15891 15888 15891  0    1 15:07 pts/1    00:00:00 /bin/sh ./run-mozilla.sh ./thunderbird-bin
craig    15895 15891 15895  2    1 15:07 pts/1    00:00:00 ./thunderbird-bin
craig    15898 15812 15898  0    1 15:07 pts/6    00:00:00 grep thunderbird

If I attach gdb to the thunderbird-bin process ( in this case, pid 15895 ) and request a backtrace, I see that it appears to be waiting on a mutex deep in libnss:

(gdb) bt
#0  0xb7fbd410 in __kernel_vsyscall ()
#1  0xb7f9b589 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7f96ba6 in _L_lock_95 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xb7f9658a in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xb6e2dc2b in ?? () from /lib/libnss_ldap.so.2
#5  0xb6e2dfe7 in ?? () from /lib/libnss_ldap.so.2
#6  0xb71fdf7f in fork () from /lib/tls/i686/cmov/libc.so.6
#7  0xb7f9e034 in fork () from /lib/tls/i686/cmov/libpthread.so.0
#8  0x08084982 in ?? ()
#9  0x08085d0d in ?? ()
#10 0x080861c0 in ?? ()
#11 <signal handler called>
#12 0x00000005 in ?? ()
#13 0xb7571365 in ?? ()
#14 0xb6e2a1f4 in ?? () from /lib/libnss_ldap.so.2
#15 0xb6e2c812 in ?? () from /lib/libnss_ldap.so.2
#16 0xb6e2d139 in ?? () from /lib/libnss_ldap.so.2
#17 0xb6e2de17 in ?? () from /lib/libnss_ldap.so.2
#18 0xb6e2e1c0 in _nss_ldap_getpwnam_r () from /lib/libnss_ldap.so.2
#19 0xb71fcaf6 in getpwnam_r () from /lib/tls/i686/cmov/libc.so.6
#20 0xb789bf06 in ?? () from /usr/lib/libglib-2.0.so.0
#21 0xb789d844 in g_get_home_dir () from /usr/lib/libglib-2.0.so.0
#22 0xb7c16590 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb7c196db in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#24 0xb7bc9aea in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#25 0xb7877b31 in g_option_context_parse () from /usr/lib/libglib-2.0.so.0
#26 0xb7bc975c in gtk_parse_args () from /usr/lib/libgtk-x11-2.0.so.0
#27 0x0807bec6 in ?? ()
#28 0x08079be6 in ?? ()
#29 0xb717e450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#30 0x08079ab1 in ?? ()

I wouldn't be too surprised if this is a binary compat issue, so I'm building trunk locally for testing. This will take some time, and I thought it best to report the issue now.

Reproducible: Always

Steps to Reproduce:
1. Download and unpack shredder daily
2. ssh from a system running X11 to the system with the daily on it using the `-X' flag
3. Invoke shreadder
Actual Results:  
thunderbird hangs early in launch

Expected Results:  
normal launch

Comment 1

[Ludovic Hirlimann [:Usul]]

What version of lib-nss is installed on your system ?

Comment 2

[Craig Ringer]

On the Ubuntu 9.04 machine the above backtrace was taken from: libnss  3.12.2~rc1-0ubuntu2, libnss-ldap 261-2.1ubuntu1 .

On the Ubuntu 8.10 machine I also tested with: libnss 3.12.0~beta3-0ubuntu1, libnss-ldap 258-1ubuntu3 .

Comment 3

[Mark Banner (:standard8)]

I believe this is most likely a duplicate of bug 292127.

Comment 4

[Craig Ringer]

It looks a lot like it. I'd say the fact that it only occurs over remote X is likely to be an nscd effect.

Replacing tbird's libldap60.so with a symlink to the system libldap works around the issue, though I don't know if it breaks tbird's ldap features. They're too limited for me to have much use for anyway.

Thanks for pointing out the dupe.