|
|
From Isaiah
Originally posted on devel list: http://slicer-devel.65872.n3.nabble.com/Slicer-startup-crash-on-fresh-build-tt4036106.html
Hi Greg,
It looks like the crash happens during initialization of OpenSSL hashing routines for hashlib, which seems to be imported by Modules/Scripted/DICOMLib/DICOMPlugin.py on launch. A few suggestions:
- did you happen to build with 'Slicer_USE_SYSTEM_OpenSSL' defined? If so, try removing that option and let Slicer build OpenSSL from scratch.
- set
Slicer_USE_PYTHONQT_WITH_OPENSSL=OFF. This should resolve the launch issue, but will likely lose some functionality. The Python DICOM plugins may still work because it only uses MD5.
As far as debugging:
- The best option is to build a debug version of Python and run it under gdb. Unfortunately, this doesn't seem to be supported by the CMake Python build script (there is a TODO for Py_DEBUG support in the CMake file).
--> You may be able to get debug symbols in an existing superbuild Python by running make OPT="-g" from $SUPERBUILD_DIR/python-build (possibly preceded by make clean).
--> If that doesn't work, copy the "$SUPERBUILD/Python-2.7.11" directory somewhere else, and do an autoconf build. You'll need to do ./configure --with-pydebug, and hopefully it will pick up your local OpenSSL version. Then run
gdb ./python-dbg
gdb> b init_hashlib
gdb> r
python> import hashlib
... and see if you can reproduce the crash.
... you could revert to GCC 4.9 (or maybe install in parallel, not sure how hard that is in Debian), but you will need to do a clean superbuild in that case, and possibly tweak the compiler paths. Changing compilers is a bit on the risky side, so don't do this on a system you can't afford to brick :)
Best,
Isaiah
[1] https://packages.qa.debian.org/o/openssl.html |
|
|
|
Confirmed that Slicer_USE_SYSTEM_OpenSSL to OFF does workaround this problem. |
|
|
|
This is a build issue on a specific configuration and a workaround is available, so I change the severity to "minor" (it helps us focusing on real crashes in production code). |
|
|
|
Behavior of this problem has changed. Setting Slicer_USE_SYSTEM_OpenSSL no longer effective; crash occurs with Slicer-built OpenSSL. The backtrace is:
Program received signal SIGSEGV, Segmentation fault.
0x00007f69280681f7 in CRYPTO_add_lock () from /home/gsharp/build/slicer-4/Slicer-debug/OpenSSL/libcrypto.so.1.0.0
bt
#0 0x00007f69280681f7 in CRYPTO_add_lock () from /home/gsharp/build/slicer-4/Slicer-debug/OpenSSL/libcrypto.so.1.0.0
0000001 0x00007f69280fc869 in EVP_PKEY_free () from /home/gsharp/build/slicer-4/Slicer-debug/OpenSSL/libcrypto.so.1.0.0
0000002 0x00007f692844847b in ssl_cert_free () from /home/gsharp/build/slicer-4/Slicer-debug/OpenSSL/libssl.so.1.0.0
0000003 0x00007f692844520f in SSL_CTX_free () from /home/gsharp/build/slicer-4/Slicer-debug/OpenSSL/libssl.so.1.0.0
0000004 0x00007f68f941ce01 in SSL_free () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
0000005 0x00007f69117df944 in ?? () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
0000006 0x00007f69117e11df in ?? () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
0000007 0x00007f69117d048d in ?? () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
0000008 0x00007f69117d0745 in QSslCertificate::fromData(QByteArray const&, QSsl::EncodingFormat) () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
0000009 0x00007f69117d0eb9 in QSslCertificate::fromPath(QString const&, QSsl::EncodingFormat, QRegExp::PatternSyntax) () from /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
0000010 0x00007f692956e081 in qSlicerCoreApplication::loadCaCertificates (slicerHome=...) at /home/gsharp/build/slicer-4/Slicer/Base/QTCore/qSlicerCoreApplication.cxx:1594
0000011 0x00007f6929566ddc in qSlicerCoreApplicationPrivate::init (this=0x56187d44d290) at /home/gsharp/build/slicer-4/Slicer/Base/QTCore/qSlicerCoreApplication.cxx:252
0000012 0x00007f692d30b1cc in qSlicerApplicationPrivate::init (this=0x56187d44d290) at /home/gsharp/build/slicer-4/Slicer/Base/QTGUI/qSlicerApplication.cxx:190
0000013 0x00007f692d30c1fc in qSlicerApplication::qSlicerApplication (this=0x7ffe97b66d80, _argc=@0x7ffe97b66c4c: 2, _argv=0x7ffe97b66f28) at /home/gsharp/build/slicer-4/Slicer/Base/QTGUI/qSlicerApplication.cxx:347
0000014 0x000056187b258e8a in (anonymous namespace)::SlicerAppMain (argc=2, argv=0x7ffe97b66f28) at /home/gsharp/build/slicer-4/Slicer/Applications/SlicerApp/Main.cxx:125
0000015 0x000056187b259edb in main (argc=2, argv=0x7ffe97b66f28) at /home/gsharp/build/slicer-4/Slicer/Applications/SlicerApp/Main.cxx:277
Debian testing
Qt 4.8.7
gcc 6.4.0
Is it possible that system Qt is not compatible with slicer-built OpenSSL? Note System Qt links with libssl.so.1.0.2 which calls Slicer-debug/OpenSSL/libssl.so.1.0.0. |
|
|
|
Update: Setting Slicer_USE_PYTHONQT_WITH_OPENSSL=OFF does seem to work. |
|
|
|
OpenSSL version used on Unix has been updated to 1.0.2n. See r26841
@gregsharp As a side note, your authorship will be restored when we transition to GitHub. See https://www.slicer.org/wiki/Documentation/Labs/TransitionToGit#Authorship |
|
|
|
Fix confirmed. Clean compile and no crash on Debian 9 (stable). Thanks Jc!! |
|
