gdb: set a breakpoint for a SIGBUS handler

Question

I\'m trying to debug a simple stop-and-copy garbage collector (written in C) using GDB. The GC works by handling SIGBUS. I\'ve set a breakpoint at the top of my SIGBUS signal ha

Answer 1

The same code (modified to handle SIGSEGV too) works as expected in GDB on Linux; it may be a bug in OS X or GDB's port to that platform.

Googling finds broken OS X behavior just like yours all the way back on 10.1, with a sort-of workaround (set inferior-bind-exception-port off before running the program).

(There's a similar bug on Windows.)

Answer 2

How about putting a for( ;; ); after the printf(), running the program normally, and then connecting to the process with gdb after GC TIME prints out?

Answer 3

Why do you expect to get a SIGBUS? SIGBUS usually means alignment error, on an architecture where some datatypes have alignment requirements. It looks like you are just trying to access memory outside your allocated area, and I would expect that you get SIGSEGV instead of SIGBUS then.

Edit:

It seems that the Mac OS X name for what I think of as SIGSEGV is SIGBUS. Therefore, ignore this answer.

If it's any help, the breakpoint works as expected (i.e., it works) when I try the program on a Linux system, with SIGBUS replaced by SIGSEGV.

Edit 2:

Can you try to catch SIGSEGV in your program too? It seems that the type of signal may vary depending on where the memory is mapped in Mac OS X (I just read the discussion here and here), and just perhaps a different signal could be thrown when you run in the debugger?

Answer 4

Internally, bad memory accesses result in the Mach exception EXC_BAD_ACCESS being sent to the program. Normally, this is translated into a SIGBUS UNIX signal. However, gdb intercepts Mach exceptions directly, before the signal translation. The solution is to give gdb the command set dont-handle-bad-access 1 before running your program. Then the normal mechanism is used, and breakpoints inside your signal handler are honored.