
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?