Do you have some examples how such an abort looks like with and without GDB?
with gdb + .gdbinit: Program received signal SIGABRT, Aborted. 0x00007fb45991e1f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); $1 = (rb_vm_t *) 0x117ef20 * #<Thread:0x11b5ef8 rb_thread_t:0x117f5e0 native_thread:0x7fb45ad27740> 0x7fb45259accc <rb_digest_class_s_digest at digest.c:459>:in `digest' (irb):5:in `irb_binding' 0x7fb45a80b318 <rb_f_eval at vm_eval.c:1437>:in `eval' /home/vagrant/.rvm/rubies/ruby-2.4.2/lib/ruby/2.4.0/irb/workspace.rb:87:in `evaluate' /home/vagrant/.rvm/rubies/ruby-2.4.2/lib/ruby/2.4.0/irb/context.rb:381:in `evaluate' /home/vagrant/.rvm/rubies/ruby-2.4.2/lib/ruby/2.4.0/irb.rb:493:in `block (2 levels) in eval_input' ... with gdb only: Program received signal SIGABRT, Aborted. 0x00007f080307f1f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x00007f080307f1f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007f08030808e8 in __GI_abort () at abort.c:90 #2 0x00007f07f9f2498f in OpenSSLDie (file=file@entry=0x7f07fa066cd3 "md5_dgst.c", line=line@entry=82, assertion=assertion@entry=0x7f07fa066cb0 "Digest MD5 forbidden in FIPS mode!") at cryptlib.c:1002 #3 0x00007f07f9f2b209 in MD5_Init (c=0x34af790) at md5_dgst.c:82 #4 0x00007f07fbcfbea0 in algo_init (algo=0x7f07fa518d60 <md5>, pctx=0x34af790) at digest.c:586 #5 0x00007f07fbcfbf4d in rb_digest_base_alloc (klass=54958520) at digest.c:606 #6 0x00007f0803e6a6de in rb_obj_alloc (klass=54958520) at object.c:1863 #7 0x00007f07fbcfbd32 in rb_digest_class_s_digest (argc=0, argv=0x7f0804387668, klass=54958520) at digest.c:472 #8 0x00007f0803f5997b in call_cfunc_m1 (func=0x7f07fbcfbccc <rb_digest_class_s_digest>, recv=54958520, argc=1, argv=0x7f0804387660) at vm_insnhelper.c:1589 ... > Why I am asking. Once we start supporting FIPS, I wonder how we are > gonna provide support for users and customers who are in FIPS mode and > "someting is breaking apart". Installing GDB would be really the last > thing to do. I wonder if there is any chance of using SystemTap or > even ABRT (Automatic Bug Reporting Tool) data (stacktrace with debug > info, core dump). Trying to find a workflow which we will use for > retrospective analysis to find the Ruby code which is causing this. > > Was wondering if we can hook into ABRT and print stacktrace similarly > as we do for: > > https://github.com/theforeman/foreman/blob/698e916ce208b5040b83a908a058c8 > 3c94d158ee/config/initializers/sig_ttin_trap.rb I tried installing an abrt signal handler when I was preparing this note, but it never gets called, possibly due to openssl calling exit immediately after raising 'abrt' [1]. Similarly, rubygem-abrt isn't catching 'abrt' signals raised by openssl. The only thing that worked for me was the approach I documented. -d [1] http://docs.huihoo.com/doxygen/openssl/1.0.1c/cryptlib_8c_source.html#l00912 -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
