I am currently debugging a segfault in one of our c++ applications and it gives me a hard time since no core files are generated when the segfault occurs.
After some reading and checking ulimits and so on I can reproduce the case of core files not being generated. It seems somehow to be related with threads. For that purpose I altered our software to artificially generate SEGV:
Now the following pattern emerges
Then in order to not alter the program itself I also tried the same with sending signals.
Then I search und /proc/< pid >/task for a non main thread and took the id
Do you know of any thread specific properties that would explain such a behaviour?
I also tried the same code under different OS and this only occurs on our production environment (redhat6) and not under Ubuntu. I am still trying to figure out if it might be related to Debug/Non-Debug builds.
Still the behavior seems so strange that it must be because of some subtlety. I also wonder, if I wanted to create this behavior on purpose I would not even know what to change, in order to achieve this.
Any help is appreciated.
Best regards Matthias
For what its worth - it had something to do with the corepattern which I found out with some trial and error
core_pattern core -> corefile
core_pattern /opt/tmp/core -> corefile
core_pattern /opt/tmp/core_%e.%p -> no corefile
core_pattern /opt/tmp/core_%e -> no corefile
core_pattern /opt/tmp/core_%h -> corefile
core_pattern /opt/tmp/core_%h_%p -> corefile
core_pattern /opt/tmp/core_%h_%p_%e -> no corefile
So the %e seems to be reason why sometimes no core is written. Then core dump filename gets thread name instead of executable name with core_pattern %e.%p.core explains what is going on - namely that %e is not the executable name but contains information about the threads - which in my case contains "/"
This also explains why segv in different threads behave differently and also why my simplest programs did not show the problem - as there was no code give names to the threads