Systemd might be a viable solution for this, however the coredump functionality is not enabled by default in OpenEmbedded (see recipes-core/systemd/systemd_xxx.bb in OpenEmbedded core). make sure that the core dumps do not use more than a certain amount of space). To enable core dumps on production systems it is highly recommended to use a daemon to manage the core dumps (e.g. Enabling core dumps on a system can fill up its mass storage over time.
Note: Depending on the memory usage of a process core files can be huge. Should you run an executable with 'suid' or 'guid' rights you also need the following: Note that these settings aren't stored persistently.Įcho "/tmp/core-%e-%s-%u-%g-%p-%t" > /proc/sys/kernel/core_pattern
The following enables core dump generation when a user process triggers a signal and sets the core file location to /tmp/ with a sensible name. Zcat /proc/config.gz | grep CONFIG_COREDUMP Zcat /proc/config.gz | grep CONFIG_ELF_CORE Check and if needed recompile the kernel with enabled core dump options. Make sure the Linux kernel has the needed configuration options set as we don't enable these by default. Such files are called core dumps and contain a snapshot of the allocated memory and registers and can later be used with gdb to analyse the causes of the signal. segmentation fault or illegal instruction. The Linux kernel can write a file containing the state of a process when the process receives certain signals, e.g. See Hello World application on Embedded Linux for a possible setup.įor cases which do not allow to run gdb core dumps can help in debugging issues with abnormal termination. This also allows to debug issues with abnormal termination caused by receiving signals. To debug an executable one can run it under control of gdbserver/gdb.
0 kommentar(er)
