mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2026-01-15 05:41:16 +01:00
77787ec9bc
BUG_ON() calls currently trigger a segfault. This is more convenient than abort() as it doesn't rely on any function call nor signal handler and never causes non-unwindable stacks when opening cores. But it adds quite some confusion in bug reports which are rightfully tagged "segv" and do not instantly allow to distinguish real segv (e.g. null derefs) from code asserts. Some CPU architectures offer various crashing methods. On x86 we have INT3 (0xCC), which stops into the debugger, and UD0/UD1/UD2. INT3 looks appealing but for whatever reason (maybe signal handling somewhere) it loses the last call point in the stack, making backtraces unusable. UD2 has the merit of being only 2 bytes and causing an invalid instruction, which almost never happens normally, so it's easily distinguishable. Here it was defined as a macro so that the line number in the core matches the one where the BUG_ON() macro is called, and the debugger shows the last frame exactly at its calligg point. E.g. when calling "debug dev bug": Program terminated with signal SIGILL, Illegal instruction. #0 debug_parse_cli_bug (args=<optimized out>, payload=<optimized out>, appctx=<optimized out>, private=<optimized out>) at src/debug.c:408 408 BUG_ON(one > zero); [Current thread is 1 (Thread 0x7f7a660cc1c0 (LWP 14238))] (gdb) bt #0 debug_parse_cli_bug (args=<optimized out>, payload=<optimized out>, appctx=<optimized out>, private=<optimized out>) at src/debug.c:408 #1 debug_parse_cli_bug (args=<optimized out>, payload=<optimized out>, appctx=<optimized out>, private=<optimized out>) at src/debug.c:402 #2 0x000000000061a69f in cli_parse_request (appctx=appctx@entry=0x181c0160) at src/cli.c:832 #3 0x000000000061af86 in cli_io_handler (appctx=0x181c0160) at src/cli.c:1035 #4 0x00000000006ca2f2 in task_run_applet (t=0x181c0290, context=0x181c0160, state=<optimized out>) at src/applet.c:449