Summary: | mail-client/thunderbird www-client/seamonkey segfault at startup if nss_ldap/openldap are installed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Stan Sander <stsander> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | beschindler, EoD, gentoo, hendrik, jaroslav.hron, phmagic, shadowdaemon, xmw, yosoy |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
strace of thunderbird
rename ldap libs backtrace on core file lddtree output strace -f of thunderbird use bundled ldap instead of system ldap r.1.0 backtrace on core file |
Description
Stan Sander
2012-05-26 20:00:51 UTC
Created attachment 313181 [details]
strace of thunderbird
turns out 10.0.4 does the same thing. So something else has gotten whacked on my system. Maybe with the strace someone can point me in a direction. (In reply to comment #2) > turns out 10.0.4 does the same thing. So something else has gotten whacked > on my system. Maybe with the strace someone can point me in a direction. start with a revdep-rebuild, if you are still having issues please get a proper backtrace. http://www.gentoo.org/proj/en/qa/backtraces.xml revdep-rebuild says everything is fine. I always run that after any world updates. I'm rebuilding tbird with the -ggdb added to CFLAGS. I'll try to get a more useful trace soon. After rebuilding xulrunner so that the debug symbols would be included, the problem no longer happens. Apparently there was an issue in my build of xulrunner that was not detected by revdep-rebuild, nor did it affect firefox which has been running fine this whole time. I have the binaries with the gdb symbols not stripped, so if the problem comes back, I can post a decent trace. (In reply to comment #5) > After rebuilding xulrunner so that the debug symbols would be included, the > problem no longer happens. Apparently there was an issue in my build of > xulrunner that was not detected by revdep-rebuild, nor did it affect firefox > which has been running fine this whole time. I have the binaries with the > gdb symbols not stripped, so if the problem comes back, I can post a decent > trace. xulrunner is not used by tb/fx in a good while, is there a particular reason you still have xulrunner on your system? On the xulrunner, didn't realize it was no longer a dependency. At some point I must have forgotten a -1 on an emerge command and it was added to my world file. I've corrected that now. On the thunderbird issue -- I read an old post somewhere where running nscd kept thunderbird from segfaulting at startup. It does help in this case....I forgot about nscd running and wasn't able to reproduce the segfault. So running nscd is an acceptable workaround, but not sure that making it a requirement for using thunderbird is a good permanent solution. Now that I have some way of working around the issue and reproducing it I tried again to get a backtrace to post -- sigh --- I'm not much good at that yet apparently. If I let thunderbird create a core file and then try to run gdb on it, gdb segfaults!!!?????!! If I run thunderbird with thunderbird -g thunderbird-bin -d gdb I can't get a useful backtrace, this is all I get from gdb: (gdb) run Starting program: /usr/lib64/thunderbird/thunderbird-bin thunderbird-bin warning: no loadable sections found in added symbol-file system-supplied DSO at 0x34800f00000 Program received signal SIGSEGV, Segmentation fault. 0x0000034800280eab in ?? () (gdb) thread apply all bt full Thread 1 (LWP 13816): #0 0x0000034800280eab in ?? () No symbol table info available. #1 0x0000000000000000 in ?? () No symbol table info available. (gdb) quit Not sure what I need to rebuild next to get the needed symbols. So far I've rebuilt glibc, nspr, and thunderbird. If nscd is working around the problem it is a known issue upstream and we are working on it. This would really be a dupe of bug 377261 I am using nss_ldap and pam_ldap as I have migrated to LDAP for authentication and no longer have local user accounts on the system. I would try nss-ldapd, but the gentoo ebuild for that seems dead. As long as nscd works, I can live with that for now. I'd help more, but coding in C/C++ is beyond my skill set. Not directly related to this bug, but any idea why gdb would crash when trying to load the core file from tbird on this bug? Should I create a bug on that and post the gdb backtrace from gdb's crash? (In reply to comment #9) > I am using nss_ldap and pam_ldap as I have migrated to LDAP for > authentication and no longer have local user accounts on the system. I > would try nss-ldapd, but the gentoo ebuild for that seems dead. As long as > nscd works, I can live with that for now. I'd help more, but coding in > C/C++ is beyond my skill set. Not directly related to this bug, but any > idea why gdb would crash when trying to load the core file from tbird on > this bug? Should I create a bug on that and post the gdb backtrace from > gdb's crash? I am actually testing something right now, if it works out here I will publish it here for you to test for us. If it resolves your problem I will push it to tree and then upstream. Created attachment 313619 [details, diff]
rename ldap libs
Drop this into /etc/portage/patches/mail-client/thunderbird and re-emerge then test with nscd disabled.
It's building with the patch....... * Done with patching * edos2unix ./db/makefiles.sh * Applying user patches from /etc/portage/patches//mail-client/thunderbird-12.0.1-r1 ... * fix_ldap_name.patch ... [ ok ] * Done with patching * Running eautoreconf in '/var/tmp/portage/mail-client/thunderbird-12.0.1-r1/work/comm-release' ... * Running autoconf ... [ ok ] Will report results later............. Created attachment 313641 [details]
backtrace on core file
Still segfaults. Attaching a backtrace on the core file. Missing some symbols from some of the libraries, so don't know if I need to re-emerge some more packages so the symbols will be available or if this is enough. Let me know, I'd be happy to re-emerge whatever needed to get a good backtrace for you. Thanks for looking at this. Got to be a nasty bug since it looks like it goes back quite a ways.
(In reply to comment #13) > Created attachment 313641 [details] > backtrace on core file > > Still segfaults. Attaching a backtrace on the core file. Missing some > symbols from some of the libraries, so don't know if I need to re-emerge > some more packages so the symbols will be available or if this is enough. > Let me know, I'd be happy to re-emerge whatever needed to get a good > backtrace for you. Thanks for looking at this. Got to be a nasty bug since > it looks like it goes back quite a ways. your bt shows libnss_ldap still please get me an lddtree of libxul, libmoz* from /usr/lib/thunderbird/ also please provide an "strace -f thunderbird 2&> thunderbird.log" Created attachment 313723 [details]
lddtree output
As requested libmoz* and libxul
Created attachment 313725 [details]
strace -f of thunderbird
As requested
(In reply to comment #16) > Created attachment 313725 [details] > strace -f of thunderbird > > As requested Your strace show you have libnss_ldap installed in /usr/lib/thunderbird can you explain this? Also you show plugins that are loading libldap can you plz check on this. No I don't know why it would think libnss_ldap is in thunderbird. $ls -ld /usr/lib lrwxrwxrwx. 1 root root 5 May 1 2009 /usr/lib -> lib64 $ls /usr/lib64/thunderbird application.ini defaults libmozprldap60.so removed-files bin distribution libxpcom.so run-mozilla.sh blocklist.xml extensions libxul.so searchplugins chrome isp mozilla-xremote-client Throbber-small.gif chrome.manifest jsloader omni.ja thunderbird components libmozalloc.so platform.ini thunderbird-bin crashreporter libmozldap60.so plugin-container xpcom-config.h crashreporter.ini libmozldif60.so plugins Running an equery g with a depth of 2 shows that curl is pulling in libldap. The ldap USE flag is enabled on curl. I actually have the ldap USE flag in my make.conf. My reasoning is that everything that can use/need ldap support will get it except for those specific packages where an exception needs to be made, then I turn the flag off in package.use. Currently the only package where I have done that is cups. Right off hand I can't think of any pressing need to have ldap support for curl, so I am re-emerging curl with the ldap flag off. I'll let you know how that goes. still segfaults, and even though I'm not good at reading a backtrace, I can see that something is still pulling in libldap. I'm going to re-emerge nss_ldap and openldap so that the debug symbols will be avail for the backtrace and see if that will help track it down. (In reply to comment #17) > (In reply to comment #16) > > Created attachment 313725 [details] > > strace -f of thunderbird > > > > As requested > > Your strace show you have libnss_ldap installed in /usr/lib/thunderbird can > you explain this? Also you show plugins that are loading libldap can you plz > check on this. I did an strace -f on thunderbird with nscd running (no segfault) and without it running (segfaults). I can see that thunderbird searches for libnss_ldap in /usr/lib64/thunderbird, but does not actually find it there. It does find it in /lib64: [pid 10675] open("/usr/lib64/thunderbird/libnss_ldap.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10675] open("/usr/lib64/thunderbird/plugins/libnss_ldap.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10675] open("/lib64/libnss_ldap.so.2", O_RDONLY|O_CLOEXEC) = 14 What is interesting is that if nscd is running, thunderbird connects to the nscd socket, if the nscd socket does not exist, it then opens libnss_{dns, files, ldap} presumably (by me) based on what it read from nsswitch.conf Here are some grep from the two traces. thunderbird.log is without nscd running and thunderbird-nscd is with nscd running: grep libnss thunderbird.log [pid 10683] open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/thunderbird/libnss3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/thunderbird/plugins/libnss3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/libnss3.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/thunderbird/libnssutil3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/thunderbird/plugins/libnssutil3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/libnssutil3.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/thunderbird/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/thunderbird/plugins/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 7 open("/usr/lib64/thunderbird/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/thunderbird/plugins/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 7 [pid 10675] open("/usr/lib64/thunderbird/libnss_ldap.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10675] open("/usr/lib64/thunderbird/plugins/libnss_ldap.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10675] open("/lib64/libnss_ldap.so.2", O_RDONLY|O_CLOEXEC) = 14 grep libnss thunderbird-nscd.log open("/usr/lib64/thunderbird/libnss3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/thunderbird/plugins/libnss3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/libnss3.so", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/thunderbird/libnssutil3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/thunderbird/plugins/libnssutil3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/libnssutil3.so", O_RDONLY|O_CLOEXEC) = 3 grep nscd thunderbird-nscd.log [pid 10614] connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = 0 [pid 10614] connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = 0 [pid 10614] connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = 0 [pid 10614] connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = 0 connect(7, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = 0 connect(7, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = 0 [pid 10606] connect(14, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = 0 [pid 10606] connect(14, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = 0 grep nscd thunderbird.log [pid 10683] connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) [pid 10683] connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) [pid 10683] connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) [pid 10683] connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) connect(7, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) connect(7, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) [pid 10675] connect(14, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) [pid 10675] connect(14, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) *** Bug 377261 has been marked as a duplicate of this bug. *** Created attachment 313907 [details, diff]
use bundled ldap instead of system ldap r.1.0
Please throw out the outdated patch and give it a spin, if all goes well I have finally forced the use of bundled ldap for thunderbird :)
Created attachment 313957 [details]
backtrace on core file
Still no joy :( I've attached the latest backtrace, but I doubt it will be all that different than the ones you've already seen. Looks to me like it is still pulling in nss_ldap:
#11 do_init () at ldap-nss.c:1351
and the exception is raised in the same call as before:
#3 strtok_r () at ../sysdeps/x86_64/strtok.S:190
No locals.
#4 0x00000331519c3ab3 in ldap_str2charray
Why not to use system ldap? Currently my only solution to run thunderbird is: cd /usr/lib64/thunderbird rm libldap60.so ln -s ../libldap.so ./libldap60.so (In reply to comment #22) > Created attachment 313907 [details, diff] [details, diff] > use bundled ldap instead of system ldap r.1.0 > > Please throw out the outdated patch and give it a spin, if all goes well I > have finally forced the use of bundled ldap for thunderbird :) I'm also hitting this bug. 3.1 and older has been masked and pending removal, but without a fix for this, removing thunderbird-3 from the tree is feels wrong. Deleting the built-in libldap solved it for me Cheers *** Bug 425540 has been marked as a duplicate of this bug. *** Any progress on solving this bug? Right now it seems that on my system if I use sys-auth/nss-pam-ldapd then thunderbird works with ldap authorization. When using sys-auth/pam_ldap, thunderbird still segfaults.... It's a clash of symbols from libldap-2.4.so and libldap60.so, namely "ldap_str2charray". A workround is to (re)start nscd in order to avoid calling the symbol. See also on the upstream bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=292127#c79 If you introduce a USE flag for ldap ( see bug 439278 ), you can disable ldap and get rid of the problem. *** Bug 463658 has been marked as a duplicate of this bug. *** If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team |