1

I'm having trouble debugging a C++ program on AIX built with GNU tools. When the program runs outside the debugger:

-bash-4.3$ ./cryptestcwd v
Segmentation fault (core dumped)

When the program runs under GDB, the debugger prints the message During startup program terminated with signal SIGKILL, Killed. and exits:

enter image description here

An added wrinkle is, this only happens with an Autotools front-end. It does not happens with our regular GNUmakefile. We supply the same arguments to both Autotools and the GNUmakefile. We are aware Autotools adds additional options and even adds C files to the C++ project, but we have no control over it.

A related question is at During startup program terminated with signal SIGKILL, Killed, but it does not have useful answers. Two other related questions just state that SIGKILL cannot be caught. Also see Debugging program that catches SIGKILL under Linux and Handling signals with gdb.

How can I debug the problem further?

jww
  • 97,681
  • 90
  • 411
  • 885
  • May need to use a tedious "divide and conquer" approach ? #ifdef out half the code, re-compile, run, repeat... – Paul R Nov 15 '17 at 18:09
  • If you run the program from the shell, without using gdb, do you get different behavior? – Mark Plotnick Nov 15 '17 at 18:26
  • You may be able to make a class with a constructor that does something meaningless but hard to compile out, force construction of this class as early as possible in the start-up process, and place a breakpoint in this constructor. From there you may be able to step through the pre-`main` code and find the cause of death. – user4581301 Nov 15 '17 at 18:30
  • @Mark - Yes, the issue is present both inside and outside the debugger. Another wrinkle is, we are trying to add an [Autotools front-end](https://github.com/noloader/cryptopp-autotools). Our regular [hand written] GNUmakefile is fine. The problem only surfaces under the Autotools binaries. And the image above is the Autotools binary. – jww Nov 15 '17 at 18:41
  • So you can easily compare the compile and link commands. – rustyx Nov 15 '17 at 18:44
  • @RustyX - Well, I'm not sure how easy it will be. We place the same options in Autotools we place in our GNUmakefile. But Autotools adds its own flags and I don't know how to stop them. And Autotools adds C source files to the project, and I don't know how to stop that behavior either. Related, see [How to disable C compiler in C++ Autotools project](https://stackoverflow.com/q/47060001/608639). And I think Libtool adding C source files is a bug; see [Bug #29298: C++ compiler, Newlib and "implicit declaration..."](https://lists.gnu.org/archive/html/bug-libtool/2017-11/msg00002.html). – jww Nov 15 '17 at 19:00
  • @OP Do examine the core file with gdb. – Lorinczy Zsigmond Nov 16 '17 at 11:11

1 Answers1

2

The SIGKILL at startup most likely means that the AIX runtime loader couldn't find some library that the binary links against (a Linux runtime loader produces a more helpful error message when that happens).

You should verify that ldd cryptestcwd doesn't complain about anything.

You could also try to load the core that is produced when you run your program outside of GDB into GDB -- there may be additional clues there (use info shared, where, x/i $pc commands).

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • 1
    Actually, unlike linux!loader, AIX!loader does explain what unresolved external prohibited the loading of the program. There is no core-dump in these cases. – Lorinczy Zsigmond Nov 16 '17 at 12:29