44 lines
1.6 KiB
Plaintext
44 lines
1.6 KiB
Plaintext
|
|
Task Completed
|
|
Perfect! The core dump limit is now set correctly. You can see both:
|
|
|
|
LimitCORE=infinity
|
|
LimitCORESoft=infinity
|
|
What happens next:
|
|
The relay is now configured to generate core dumps when it crashes
|
|
Wait for the next crash to occur (based on your logs, it seems to happen intermittently)
|
|
When it crashes, the core dump will be automatically captured by systemd
|
|
After the next crash, analyze it:
|
|
# List all core dumps (most recent first)
|
|
sudo coredumpctl list
|
|
|
|
# View info about the most recent c-relay crash
|
|
sudo coredumpctl info c-relay
|
|
|
|
# Load the core dump in gdb for detailed analysis
|
|
sudo coredumpctl gdb c-relay
|
|
|
|
Inside gdb, run these commands:
|
|
(gdb) bt full # Full backtrace with all variables
|
|
(gdb) info threads # Show all threads
|
|
(gdb) thread apply all bt # Backtrace for all threads
|
|
(gdb) frame 0 # Go to crash frame
|
|
(gdb) info locals # Show local variables
|
|
(gdb) list # Show source code around crash
|
|
|
|
The backtrace will show you exactly which line of code caused the segmentation fault and the state of all variables at that moment, which should pinpoint whether it's the subscription management issue, buffer overflow, or something else.
|
|
|
|
You're all set up now - just wait for the next crash and then run the coredumpctl commands to analyze it.
|
|
|
|
|
|
--------------------------
|
|
|
|
|
|
Even simpler: Use this one-liner
|
|
# Start relay and immediately attach gdb
|
|
cd /usr/local/bin/c_relay
|
|
sudo -u c-relay ./c_relay --debug-level=5 & sleep 2 && sudo gdb -p $(pgrep c_relay)
|
|
|
|
Once gdb attaches, type continue and wait for the crash. This way the relay starts normally and gdb just monitors it.
|
|
|
|
Which approach would you like to try? |