Frequenty Asked Questions
Send some process the SEGV signal and check if minicoredumper reacted.
minicoredumper uses syslog(3) to log its activity. The syslog ident is minicoredumper and the syslog facility is LOG_SYSLOG. Typically this output will land in /var/log/syslog.
After an application core dumps, a new directory containing the generated core file should have been created in the base_dir configured in the minicoredumper configuration file.
No. The current version of minicoredumper does not use D-Bus. Versions 1.x of the minicoredumper optionally used D-Bus for libminicoredumper dump notification, whereby libminicoredumper applications were responsible for dumping their own data upon notification. This mechanism has since been replaced. Now application dump data is extracted by the minicoredumper tool instead.
In general, a minimal recept file to satisfy gdb would look like this:
{
"stacks": {
"dump_stacks": true
},
"maps": {
"dump_by_name": [
"[vdso]"
]
},
"dump_auxv_so_list": true,
"dump_pthread_list": true,
"dump_robust_mutex_list": true
}
However, depending upon the application and what needs to be inspected, even some of these options may be disabled. See the recept file man page for details about each of these options.
There are some symbols that minicoredumper will need to find. These should not be stripped from their libraries and executables.
- Any symbols specified as buffers in the recept file must not be stripped.
- Although normally not needed, minicoredumper will fallback to manually check for some symbols in libpthread if the crashing application is using a libpthread that is incompatible with the libthread_db minicoredumper is using. Those libpthread symbols are:
- _thread_db_sizeof_pthread
- stack_used
- __stack_user
By default, no sections are dumped in their entirety. Much of the dynamic loader sections are included in order to build the linked library lists. And if enabled, the used portion of stacks are also included. All non-stack application data (whether static data or dynamically allocated data in the heap) must be explicitly specified. This can be done by:
- specifying maps in the recept file
- specifying buffers in the recept file
- if the application is using libminicoredumper, it can register specific data for dumping with mcd_dump_data_register_bin()
Using the tool nm on the library or executable containing the symbol, it is possible to see the name of the symbol as used by the linker. This name can be specified as one of the buffers of a recept file.
As an alternative, if the application is using libminicoredumper, it can register specific data for dumping with mcd_dump_data_register_bin().
If a stack is truncated because of the max_stack_size option, the bottommost part of the used stack is dumped (i.e. the part of the stack that includes the function that caused the core dump).
For indirect pointers, the first word of the dumped file is pointer data. This is necessary for binary reinjection using the coreinject tool.
No. If minicoredumper is being used as the core dump facility, the resource limits regarding core file size are ignored. It is not possible to enforce core size limits with minicoredumper. It is recommended that a fixed size filesystem is used as the base_dir for dumps.
This kernel parameter sets the maximum number of minicoredumper instances that can run simultaneously. For example, with a value of 1 and two programs crashing simultaneously, only one of programs will generate a core dump. The kernel uses a default value of 0, which is a special value that allows unlimited simultaneous minicoredumper instances, but the kernel will not wait for the minicoredumper to exit before cleaning up the crashing program resources. More details about this parameter are available in the core(5) manual page.
Because of how the minicoredumper works, the default value of 0 allows the core dumping to work correctly. However, it is recommended to set the maximum value 0x7fffffff to be sure that it also works correctly for future kernel versions.