To debug certain crashes in realtime components it would make sense to enable coredumps. Basically limits need to be set appropriately (e.g. via systemd-coredump), and you need to set sysctl fs.suid_dumpable = 2 to allow dumping of setuid binaries. It looks like uspace_rtapi_app does explicitely enable coredumps.
But there is something puzzling (to me at least): to get the thing to actually dump to disc, I also need to replace
"raise(sig)" with "kill(getpid(), sig);".
Man page says that for singlethreaded apps these 2 instructions are equivalent. rtapi_app usually consists of >=2 threads AFAIU, one running with non-critical priority, and one or more with realtime priority.
I'm not sure where this "kill(getpid(), sig)" is sending the signal, I suspect to the main non-realtime thread, and there the actual core dump can happen.
So if anybody knows what's going on, please chime in.
To debug certain crashes in realtime components it would make sense to enable coredumps. Basically limits need to be set appropriately (e.g. via systemd-coredump), and you need to set sysctl
fs.suid_dumpable = 2to allow dumping of setuid binaries. It looks like uspace_rtapi_app does explicitely enable coredumps.But there is something puzzling (to me at least): to get the thing to actually dump to disc, I also need to replace
linuxcnc/src/rtapi/uspace_rtapi_app.cc
Line 692 in bd96ca8
Man page says that for singlethreaded apps these 2 instructions are equivalent. rtapi_app usually consists of >=2 threads AFAIU, one running with non-critical priority, and one or more with realtime priority.
I'm not sure where this "kill(getpid(), sig)" is sending the signal, I suspect to the main non-realtime thread, and there the actual core dump can happen.
So if anybody knows what's going on, please chime in.