| Summary: | Libraries from both dev-libs/openssl-1.0.0a and -0.9.8-r1 are used at the same time | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
| Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
stacktrace of firefox crash
stacktrace of firefox crash (with splitdebug) |
||
|
Description
Dennis Schridde
2010-07-20 11:42:08 UTC
You obviously haven't done "revdep-rebuild --library libssl.so.0.9.8" and "revdep-rebuild --library libcrypto.so.0.9.8" like the openssl postinst message told you to, and like the upstream bug, this is INVALID because of it (In reply to comment #1) > You obviously haven't done "revdep-rebuild --library libssl.so.0.9.8" and > "revdep-rebuild --library libcrypto.so.0.9.8" like the openssl postinst message > told you to, and like the upstream bug, this is INVALID because of it Thanks for the tip. a) I assumed @preserved-rebuild would already take care of everything revdep-rebuild did. Especially in this case it was "clear", because @preserved-rebuild contained a lot of packages that had to be rebuilt because of them linking against openssl 0.9.8. b) einfo, ewarn, etc are getting more and more crowded with things I have read again everytime I update the package. Accidentally skipping pieces of information seems inevitable. c) and reason for reopen: revdep-rebuild --library libssl.so.0.9.8 ; revdep-rebuild --library libcrypto.so.0.9.8 rebuild only dev-libs/openssl-0.9.8o-r1, app-emulation/emul-linux-x86-baselibs-20100611 and app-emulation/emul-linux-x86-gtklibs-20100611. The crashes still happen. What happens if you "emerge -C =dev-libs/openssl-0.9.8o-r1" and make sure the libcrypto.so.0.9.8 and libssl.so.0.9.8 are deleted from /usr/lib. And then try to run those apps? What I'm after here is the exact binary that is still linked against those, or is trying to dlopen them. Because, I'm suspecting you have some cruft in /usr/local or similar path. Since revdep-rebuild came out clean... `lddtree` on mumble's binary (or whatever is opening both) might also reveal the source of problem Created attachment 239551 [details]
stacktrace of firefox crash
lddtree /usr/bin/mumble | grep 0.9.8 spit out nothing.
The firefox crash I mentioned earlier is actually a bit different. stacktrace attached. It happens whenever I try to print a website...
Starting mumble after unmerging openssl:0.9.8 results in this:
[New Thread 0x7fffe7017710 (LWP 20921)]
OpenSSL Support: 1
SSL: Added CA certificates from '/etc/ssl/certs/ca-certificates.crt'
No ciphers of at least 128 bit found
Program received signal SIGABRT, Aborted.
0x00007ffff3790545 in raise () from /lib/libc.so.6
(gdb) bt full
#0 0x00007ffff3790545 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0x00007ffff3791d50 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0x00007ffff490964c in qt_message_output(QtMsgType, char const*) () from /usr/lib64/qt4/libQtCore.so.4
No symbol table info available.
#3 0x00007ffff4909822 in qt_message(QtMsgType, char const*, __va_list_tag*) () from /usr/lib64/qt4/libQtCore.so.4
No symbol table info available.
#4 0x00007ffff49099c5 in qFatal(char const*, ...) () from /usr/lib64/qt4/libQtCore.so.4
No symbol table info available.
#5 0x00000000004cc7c1 in ?? ()
No symbol table info available.
#6 0x00000000004a73e4 in ?? ()
No symbol table info available.
#7 0x00007ffff377bb8d in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#8 0x0000000000435029 in ?? ()
No symbol table info available.
#9 0x00007fffffffd9e8 in ?? ()
No symbol table info available.
#10 0x000000000000001c in ?? ()
No symbol table info available.
#11 0x0000000000000001 in ?? ()
No symbol table info available.
#12 0x00007fffffffddc9 in ?? ()
No symbol table info available.
#13 0x0000000000000000 in ?? ()
No symbol table info available.
$ grep 0\\.9\\.8 /usr/lib/qt4/*.so Binary file /usr/lib/qt4/libQtNetwork.so matches (The string matched is exactly "0.9.8", according to "strings") So for some reason revdep rebuild fails to detect that qt-network links against openssl 0.9.8? (In reply to comment #7) > $ grep 0\\.9\\.8 /usr/lib/qt4/*.so > Binary file /usr/lib/qt4/libQtNetwork.so matches > (The string matched is exactly "0.9.8", according to "strings") > > So for some reason revdep rebuild fails to detect that qt-network links against > openssl 0.9.8? > Got a binary installation of Qt4 somewhere in LDPATH? Try ldconfig -p |grep QtNetwork It should only print out the ones in /usr/lib (and possible in /usr/lib32 for emul- pkgs). ~ # ldconfig -p |grep QtNetwork
libQtNetwork.so.4 (libc6,x86-64) => /usr/lib/qt4/libQtNetwork.so.4
libQtNetwork.so.4 (libc6) => /usr/lib32/qt4/libQtNetwork.so.4
libQtNetwork.so (libc6,x86-64) => /usr/lib/qt4/libQtNetwork.so
libQtNetwork.so (libc6) => /usr/lib32/qt4/libQtNetwork.so
And try to recompile x11-libs/qt-core and see if that helps. And the firefox trace looks rather useless... might want to try "c_rehash /etc/ssl/certs" Created attachment 239553 [details]
stacktrace of firefox crash (with splitdebug)
(In reply to comment #10) > And try to recompile x11-libs/qt-core and see if that helps. I already played with that idea, but postponed it to ensure the issue stays reproducable and thus the cause can be found. Will try it when I have time again, which will be next week. (In reply to comment #11) > Created an attachment (id=239553) [details] > stacktrace of firefox crash (with splitdebug) P.S: This was after running c_rehash. (In reply to comment #6) > Created an attachment (id=239551) [details] > stacktrace of firefox crash > > lddtree /usr/bin/mumble | grep 0.9.8 spit out nothing. > > The firefox crash I mentioned earlier is actually a bit different. stacktrace > attached. It happens whenever I try to print a website... > > Starting mumble after unmerging openssl:0.9.8 results in this: > [New Thread 0x7fffe7017710 (LWP 20921)] > OpenSSL Support: 1 > SSL: Added CA certificates from '/etc/ssl/certs/ca-certificates.crt' > No ciphers of at least 128 bit found > > Program received signal SIGABRT, Aborted. > 0x00007ffff3790545 in raise () from /lib/libc.so.6 > (gdb) bt full > #0 0x00007ffff3790545 in raise () from /lib/libc.so.6 > No symbol table info available. > #1 0x00007ffff3791d50 in abort () from /lib/libc.so.6 > No symbol table info available. > #2 0x00007ffff490964c in qt_message_output(QtMsgType, char const*) () from > /usr/lib64/qt4/libQtCore.so.4 > No symbol table info available. > #3 0x00007ffff4909822 in qt_message(QtMsgType, char const*, __va_list_tag*) () > from /usr/lib64/qt4/libQtCore.so.4 > No symbol table info available. > #4 0x00007ffff49099c5 in qFatal(char const*, ...) () from > /usr/lib64/qt4/libQtCore.so.4 > No symbol table info available. > #5 0x00000000004cc7c1 in ?? () > No symbol table info available. > #6 0x00000000004a73e4 in ?? () > No symbol table info available. > #7 0x00007ffff377bb8d in __libc_start_main () from /lib/libc.so.6 > No symbol table info available. > #8 0x0000000000435029 in ?? () > No symbol table info available. > #9 0x00007fffffffd9e8 in ?? () > No symbol table info available. > #10 0x000000000000001c in ?? () > No symbol table info available. > #11 0x0000000000000001 in ?? () > No symbol table info available. > #12 0x00007fffffffddc9 in ?? () > No symbol table info available. > #13 0x0000000000000000 in ?? () > No symbol table info available. > This is related to cups, has nothing to do with ssl, cc yourself on bug #325469 (In reply to comment #12) > (In reply to comment #10) > > And try to recompile x11-libs/qt-core and see if that helps. > I already played with that idea, but postponed it to ensure the issue stays > reproducable and thus the cause can be found. > Will try it when I have time again, which will be next week. > The Firefox issue, as Jory pointed out in Comment #14 is unrelated. And after investigating futher, Qt4 doesn't *link* against OpenSSL but it *dlopen*'s it, so revdep-rebuild and preserved-libs won't be able to detect it. This is by design. You can see this in src/network/ssl/qsslsocket_openssl_symbols.cpp in Qt4 sources. So I assume rebuilding qt-core will make the problem go away... reopen if not. also this propably means we have to do a dummy revision bump of qt-core when openssl-1 goes stable... so people get the rebuild automatically... sigh... :-/ rebuilding qt-core solves the problem, lets hope no other lib dlopens ssl 0.9.8... |
