Crashing C++ application including ada dll does not generate core dump

Question

How do I get a C++ application including a loaded ada shared library to generate a core dump?

I have a C++ application which loads a ada shared library, inside the ada code I get a stack overflow error which causes program termination along with the console output:

raised STORAGE ERROR

No core dump file is generated even thou I have issued a "ulimit -c unlimited" before starting the application.

Same thing happens if I send a kill SIGSEGV to the application.

Sending kill SIGSEGV to another application that does not use the ada dll generates a core dump file just the way I want it to.

Found some information here: http://objectmix.com/ada/301203-gnat-fstack-check-does-work.html

UPDATED! As mentioned by Adrien, there is no contradiction, -s sets the stack limit while -c sets the core file limit.

Still the problem remains. I checked the flags when building the ada library and the fstack-check flag was not set, so it should generate a core dump.

Althou I haven't tried it yet, it seems somewhat strange. It mentions the -fstack-check compiler option + setting the GNAT_STACK_LIMIT variable but at the same time refers to the ulimit command which seems like a contradiction, setting "ulimit -c " is the only way I know of getting a core dump to be generated at the time of crash, if this infers with the fstack-check option then we have a catch 22.

Answer 1

This looks to me like a really good use for your AdaCore support. You aren't liable to find a whole lot of folk outside that company who are that familiar with the implications of the interactions between Gnu Ada's runtime and C++'s.

I would suggest for debugging the Ada code that you try putting in a last-ditch exception handler around everything, which in turn dumps the exception stack. Most vendors have some way of doing that, usually based off of Ada.Exceptions.Exception_Information and Ada.Exceptions.Exception_Message.

Answer 2

I found a discussion from a security perspective (finding malware). Basically there are 10 signals that you can try, SIGSEGV is only one of them.

Answer 3

It seems you can simply call sigaction(SIGSEGV, 0, SIG_DFL); to restore the default signal behavior.