Hide Forgot
Description of problem: After installing all offered updates on my Fedora-14 system yesterday, I found that Thunderbird would no longer start. When using the start menu, no window would appear. I also tried running from a command prompt. there was no output in the terminal window and no Thunderbird GUI. I tried 'thunderbird -safe-mode' with the same result. I also tried renaming $HOME/.thunderbird as $HOME/.thunderbird.old and rerunning with the same result. Running 'strace -p <pid>', where <pid> is the process id of the thunderbird-bin process shows Process 12737 attached - interrupt to quit futex(0x7f860eb57ce0, FUTEX_WAIT_PRIVATE, 2, NULL Version-Release number of selected component (if applicable): thunderbird-3.1.9-1.fc14.x86_64 thunderbird-lightning-1.0-0.39.b3pre.fc14.x86_64 How reproducible: 100% of the time Steps to Reproduce: 1. Start thunderbird Actual results: No Thunderbird window Expected results: A Thunderbird window Additional info:
I forgot to mention that after downgrading to thunderbird-3.1.4-1.fc14.x86_64 thunderbird-lightning-1.0-0.28.b2pre.fc14.x86_64 Thunderbird works fine again.
Does it start without thunderbird-lightning?
(In reply to comment #2) > Does it start without thunderbird-lightning? In short: No. In long: % rpm -e thunderbird-lightning % yum update thunderbird (To version 3.1.9-1.fc14) % mv .thunderbird .thunderbird~ % thunderbird -safe-mode Nothing happens. strace shows the same futex() call. After the downgrade to '3.1.7-2.fc14' everything runs fine.
(In reply to comment #3) > (In reply to comment #2) > > > Does it start without thunderbird-lightning? > > In short: No. > > In long: > > % rpm -e thunderbird-lightning > % yum update thunderbird > (To version 3.1.9-1.fc14) > % mv .thunderbird .thunderbird~ > % thunderbird -safe-mode > Nothing happens. > > strace shows the same futex() call. > > After the downgrade to '3.1.7-2.fc14' everything runs fine. Same result for me.
Same here
(In reply to comment #0) > Process 12737 attached - interrupt to quit > futex(0x7f860eb57ce0, FUTEX_WAIT_PRIVATE, 2, NULL The interesting thing in the strace output is the following line that will apear a little bit earlier than the futex() call: > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
(In reply to comment #3) > strace shows the same futex() call. Could we get that strace attached, please? Also, make sure (with pgrep -f -l thunderbird) that no other instance of thunderbird is running before trying to start a new one. Thank you
Created attachment 487064 [details] strace of "thunderbird -safe-mode" (thunderbird-3.1.9-1.fc14.x86_64) % pgrep -f -l thunderbird % su - yum update -y thunderbird % mv .thunderbird .thunderbird~ % strace -o thunderbird.strace -fF thunderbird -safe-mode CTRL-C after some seconds... The last futex call is the hanging one (line 32641), the segfault is in line 32470.
Is there still additional info needed on this? It looks to me like Erik supplied everything that was requested.
(In reply to comment #9) > Is there still additional info needed on this? It looks to me like Erik > supplied everything that was requested. No, that's it. Thanks.
FWIW, thunderbird-3.1.10-1.fc14 (x86_64) still exhibits this problem.
No news about this issue?
Can people affected by this try starting up nscd and see if thunderbird still crashes? In the strace posted here, as well as my private one, thunderbird crashes after failing to connect to the nscd socket and then getting some dns info by itself. Starting nscd solved the issue for me. Of course, it's not a real solution, but it could be a reasonable workaround until the real problem is fixed upstream.
I can confirm that. With nscd running it works, without, crushes.
I'm seeing this on F15-x86-64, with thunderbird 3.1.11-1, NFS home dirs, LDAP auth. I'll try the nscd idea shortly.
Strace is nice but I could be handy to get backtrace too. To get backtrace use following command(s): thunderbird -g (after gdb starts) run (after crash) t a a bt (shows backtrace for all threads) Please attach this backtrace (could be quite long).
F-15, 64-bit. (gdb) run Starting program: /usr/lib64/thunderbird-3.1/thunderbird-bin [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. strtok_r () at ../sysdeps/x86_64/strtok.S:190 190 movb $0, (%rdx) /* Terminate string. */ (gdb) t a a bt Thread 1 (Thread 0x7ffff70c19c0 (LWP 8286)): #0 strtok_r () at ../sysdeps/x86_64/strtok.S:190 #1 0x00007ffff797b361 in ldap_str2charray (str=<optimized out>, brkstr= 0x7ffff03a2b5f ", ") at charray.c:218 #2 0x00007ffff038c336 in ldap_url_parselist_int (ludlist=0x7ffff05ae160, url=<optimized out>, sep=<optimized out>, flags=11) at ../../../libraries/libldap/url.c:1293 #3 0x00007ffff038dbcb in ldap_int_initialize_global_options (gopts= 0x7ffff05ae0a0, dbglvl=<optimized out>) at ../../../libraries/libldap/init.c:534 #4 0x00007ffff038dd5d in ldap_int_initialize (gopts=0x7ffff05ae0a0, dbglvl=<optimized out>) at ../../../libraries/libldap/init.c:650 #5 0x00007ffff0373829 in ldap_create (ldp=0x7fffffffb818) at ../../../libraries/libldap/open.c:108 #6 0x00007ffff0373cff in ldap_initialize (ldp=0x7ffff07c37a0, url= 0x7ffff07c4173 "ldap://192.168.0.3") at ../../../libraries/libldap/open.c:240 #7 0x00007ffff05b3704 in do_init_session (res_init_hack=1, defport=0, uri=<optimized out>, ld=<optimized out>) at ldap-nss.c:1091 #8 do_init () at ldap-nss.c:1392 #9 0x00007ffff05b517c in _nss_ldap_search_s (args=0x7fffffffd2b0, filterprot= 0x7ffff07c8620 "(&(objectClass=posixAccount)(uid=%s))", sel=LM_PASSWD, ---Type <return> to continue, or q <return> to quit--- user_attrs=0x0, sizelimit=1, res=0x7fffffffd230) at ldap-nss.c:3137 #10 0x00007ffff05b6824 in _nss_ldap_getbyname (args=0x7fffffffd2b0, result= 0x7fffffffd380, buffer=0x7ffff6e24800 "named", buflen=1024, errnop= 0x7ffff70c1790, filterprot= 0x7ffff07c8620 "(&(objectClass=posixAccount)(uid=%s))", sel=LM_PASSWD, parser=0x7ffff05b6d80 <_nss_ldap_parse_pw>) at ldap-nss.c:3557 #11 0x00007ffff05b712b in _nss_ldap_getpwnam_r (name=0x7fffffffee34 "limb", result=0x7fffffffd380, buffer=0x7ffff6e24800 "named", buflen=1024, errnop= 0x7ffff70c1790) at ldap-pwd.c:250 #12 0x000000394a4aa75d in __getpwnam_r (name=0x7fffffffee34 "limb", resbuf= 0x7fffffffd380, buffer=0x7ffff6e24800 "named", buflen=1024, result= 0x7fffffffd3b8) at ../nss/getXXbyYY_r.c:256 #13 0x00000030e4874338 in g_get_any_init_do () at gutils.c:1702 #14 0x00000030e4875215 in g_get_any_init () at gutils.c:1853 #15 g_get_any_init_locked () at gutils.c:1860 #16 g_get_home_dir () at gutils.c:1934 #17 0x00000033a83a1d96 in gtk_rc_add_initial_default_files () at gtkrc.c:540 #18 gtk_rc_add_initial_default_files () at gtkrc.c:502 #19 0x00000033a83a61af in _gtk_rc_init () at gtkrc.c:870 #20 0x00000033a834b905 in do_post_parse_initialization (argc=<optimized out>, argv=<optimized out>) at gtkmain.c:754 #21 post_parse_hook (context=<optimized out>, group=<optimized out>, data= 0x7ffff6e050b0, error=0x7fffffffd5c8) at gtkmain.c:798 ---Type <return> to continue, or q <return> to quit--- #22 0x00000030e484f43c in g_option_context_parse (context=<optimized out>, argc=0x16e59c0, argv=<optimized out>, error=<optimized out>) at goption.c:1961 #23 0x00000033a834be30 in IA__gtk_parse_args (argc=0x16e59c0, argv=0x16e59b8) at gtkmain.c:955 #24 0x0000000000444d7f in XRE_main (argc=<optimized out>, argv=<optimized out>, aAppData=<optimized out>) at nsAppRunner.cpp:3068 #25 0x00000000004421fc in main (argc=1, argv=0x7fffffffdf08) at nsMailApp.cpp:104 (gdb)
Still happens after update to 5.0-1. Thread 1 (Thread 0x7ffff5a6b9c0 (LWP 28192)): #0 strtok_r () at ../sysdeps/x86_64/strtok.S:190 #1 0x000000323720a361 in ldap_str2charray (str=<optimized out>, brkstr=0x7fffeeda2b5f ", ") at charray.c:218 #2 0x00007fffeed8c336 in ldap_url_parselist_int (ludlist=0x7fffeefae160, url=<optimized out>, sep=<optimized out>, flags=11) at ../../../libraries/libldap/url.c:1293 #3 0x00007fffeed8dbcb in ldap_int_initialize_global_options (gopts=0x7fffeefae0a0, dbglvl=<optimized out>) at ../../../libraries/libldap/init.c:534 #4 0x00007fffeed8dd5d in ldap_int_initialize (gopts=0x7fffeefae0a0, dbglvl=<optimized out>) at ../../../libraries/libldap/init.c:650 #5 0x00007fffeed73829 in ldap_create (ldp=0x7fffffffb898) at ../../../libraries/libldap/open.c:108 #6 0x00007fffeed73cff in ldap_initialize (ldp=0x7fffef1c37a0, url=0x7fffef1c4173 "ldap://192.168.0.3") at ../../../libraries/libldap/open.c:240 #7 0x00007fffeefb3704 in do_init_session (res_init_hack=1, defport=0, uri=<optimized out>, ld=<optimized out>) at ldap-nss.c:1091 #8 do_init () at ldap-nss.c:1392 #9 0x00007fffeefb517c in _nss_ldap_search_s (args=0x7fffffffd330, filterprot=0x7fffef1c8620 "(&(objectClass=posixAccount)(uid=%s))", sel=LM_PASSWD, user_attrs=0x0, sizelimit=1, res=0x7fffffffd2b0) at ldap-nss.c:3137 #10 0x00007fffeefb6824 in _nss_ldap_getbyname (args=0x7fffffffd330, result=0x7fffffffd400, buffer=0x7ffff581e800 "named", buflen=1024, errnop=0x7ffff5a6b910, filterprot= 0x7fffef1c8620 "(&(objectClass=posixAccount)(uid=%s))", sel=LM_PASSWD, parser=0x7fffeefb6d80 <_nss_ldap_parse_pw>) at ldap-nss.c:3557 #11 0x00007fffeefb712b in _nss_ldap_getpwnam_r (name=0x7fffffffee34 "limb", result=0x7fffffffd400, buffer=0x7ffff581e800 "named", buflen=1024, errnop=0x7ffff5a6b910) at ldap-pwd.c:250 #12 0x000000394a4aa75d in __getpwnam_r (name=0x7fffffffee34 "limb", resbuf=0x7fffffffd400, buffer=0x7ffff581e800 "named", buflen=1024, result=0x7fffffffd438) at ../nss/getXXbyYY_r.c:256 #13 0x00000030e4874338 in g_get_any_init_do () at gutils.c:1702 #14 0x00000030e4875215 in g_get_any_init () at gutils.c:1853 #15 g_get_any_init_locked () at gutils.c:1860 #16 g_get_home_dir () at gutils.c:1934 #17 0x00000033a83a1d96 in gtk_rc_add_initial_default_files () at gtkrc.c:540 #18 gtk_rc_add_initial_default_files () at gtkrc.c:502 #19 0x00000033a83a61af in _gtk_rc_init () at gtkrc.c:870 #20 0x00000033a834b905 in do_post_parse_initialization (argc=<optimized out>, argv=<optimized out>) at gtkmain.c:754 #21 post_parse_hook (context=<optimized out>, group=<optimized out>, data=0x7ffff58050c8, error=0x7fffffffd648) at gtkmain.c:798 #22 0x00000030e484f43c in g_option_context_parse (context=<optimized out>, argc=0x7ffff7f9c050, argv=<optimized out>, error=<optimized out>) at goption.c:1961 #23 0x00000033a834be30 in IA__gtk_parse_args (argc=0x7ffff7f9c050, argv=0x7ffff7f9c048) at gtkmain.c:955 #24 0x00007ffff6508a8b in XRE_main (argc=<optimized out>, argv=<optimized out>, aAppData=<optimized out>) at nsAppRunner.cpp:3250 #25 0x00000000004017c3 in main (argc=1, argv=0x7fffffffdfe8) at nsMailApp.cpp:104
The problem is created by loading up two different versions of libldap in the same address space. thunderbird is linked against its own ldap libraries: $ ldd /usr/lib/thunderbird-3.1/thunderbird-bin | grep ldap libldap60.so => /usr/lib/thunderbird-3.1/libldap60.so (0x00280000) libprldap60.so => /usr/lib/thunderbird-3.1/libprldap60.so (0x00f85000) If nscd is not running, glibc ends up loading up its own nss modules to do name lookups. With ldap configured as one of the name lookup mechanisms in nsswitch.conf, glibc loads up nss_ldap.so, which pulls in the system ldap libraries: $ ldd /usr/lib/libnss_ldap.so | grep ldap libldap-2.4.so.2 => /usr/lib/libldap-2.4.so.2 (0x0047e000) and the result is a crash...
Any update? We've seen several updates to Thunderbird, and it still works on some systems, unless I'm using LDAP. It's kind of a big deal for me. I'm getting by with alpine and webmail, but. . .
Do you still suffer from this bug? If so, what so your recent system configuration?
I expect the /usr/lib/libnss_ldap.so comes from nss_ldap package, right?
Well, I gave up on Thunderbird quite some time ago...
Okay, thanks for letting us know.