Open vctibor opened 4 years ago
In order to judge whether this issue needs a follow-up, would you be able to run softhsm2-util
in gdb
and produce a stack trace when the segmentation fault occurs?
I've never before used gdb
so I hope I'm doing it right.
gdb --args softhsm2-util --show-slots
(gdb) backtrace
#0 0x00007f372afe0bd0 in ?? ()
#1 0x00007f372b7273ca in OPENSSL_cleanup () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
#2 0x00007f372b205a27 in __run_exit_handlers (status=0, listp=0x7f372b3a7718 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#3 0x00007f372b205be0 in __GI_exit (status=<optimized out>) at exit.c:139
#4 0x00007f372b1e30ba in __libc_start_main (main=0x55fab587a270 <main(int, char**)>, argc=2, argv=0x7ffdf53c2178,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdf53c2168)
at ../csu/libc-start.c:342
#5 0x000055fab587aa3e in _start () at softhsm2-util.cpp:306
gdb --args softhsm2-util --init-token --slot 0 --label "test" --so-pin 1234 --pin 1234
(gdb) backtrace
#0 0x00007f84e6610bd0 in ?? ()
#1 0x00007f84e6d573ca in OPENSSL_cleanup () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
#2 0x00007f84e6835a27 in __run_exit_handlers (status=1, listp=0x7f84e69d7718 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#3 0x00007f84e6835be0 in __GI_exit (status=<optimized out>) at exit.c:139
#4 0x00007f84e68130ba in __libc_start_main (main=0x55f3d429f270 <main(int, char**)>, argc=10, argv=0x7fff22c9daf8,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff22c9dae8)
at ../csu/libc-start.c:342
#5 0x000055f3d429fa3e in _start () at softhsm2-util.cpp:306
gdb --args softhsm2-util --import keystore.pem --slot 1904299556 --label "test_keys" --id BABA --pin 1234 --file-pin password --force
(gdb) backtrace
#0 0x00007f87d3887bd0 in ?? ()
#1 0x00007f87d3fce3ca in OPENSSL_cleanup () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
#2 0x00007f87d3aaca27 in __run_exit_handlers (status=0, listp=0x7f87d3c4e718 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#3 0x00007f87d3aacbe0 in __GI_exit (status=<optimized out>) at exit.c:139
#4 0x00007f87d3a8a0ba in __libc_start_main (main=0x55ae86818270 <main(int, char**)>, argc=14, argv=0x7fff2c4b5fc8,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff2c4b5fb8)
at ../csu/libc-start.c:342
#5 0x000055ae86818a3e in _start () at softhsm2-util.cpp:306
Are you using the HEAD version from the repository, or did you download a release tarball? This looks like it is related to open issue #551 which still needs to be evaluated and merged. If you can confirm what version you use, we may have to put this on hold until #551 has been merged.
I am using head from default branch in git, as I didn't find release tarballs at first. I can try with tarball later.
The release tarball should work, but the problem you report will likely need fixing (and should be fixed when #551 is merged), thanks for reporting this.
Putting this on hold.
Linking these issues together - I am seeing the exact same issue - every operation ends with a segfault - but in this case softhsm is being called from NSS, rather than OpenSSL, and is crashing while cleaning up mutexes. The common denominator is that both crashes are happening during atexit.
I run SoftHSM in Ubuntu-based Docker image like this:
Then any operation with
softhsm2-util
ends with segmentation fault like this:Operations seem to succeed, for example tokens get initialized, etc., but it doesn't exactly raise confidence that everything works as expected. And it may be sign of some deeper underlying issue. I have reports that the same thing happens on MacOS.
I just wanted to bring this to your attention. If you are aware of this and don't consider it problem, feel free to close the issue.