title has most likely cause. originally reported as a bug in the Go compiler: http://code.google.com/p/go/issues/detail?id=2818 but closer inspection (gdb gdb) reveals (this stack trace from 7.3.1 built from ports on FreeBSD 9.0 release) Program received signal SIGBUS, Bus error. [Switching to Thread 802c07400 (LWP 100131)] 0x0000000000500a65 in bpstat_what (bs_head=0x8030652c0) at breakpoint.c:4579 4579 switch (b->type) #0 0x0000000000500a65 in bpstat_what (bs_head=0x8030652c0) at breakpoint.c:4579 #1 0x0000000000564f95 in handle_inferior_event (ecs=0x7fffffffd400) at infrun.c:4144 #2 0x0000000000561dd3 in wait_for_inferior (treat_exec_as_sigtrap=0) at infrun.c:2610 #3 0x00000000005610b3 in proceed (addr=34366555520, siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:2136 #4 0x000000000055a360 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) at infcmd.c:600 #5 0x000000000055a3a0 in run_command (args=0x0, from_tty=1) at infcmd.c:610 #6 0x00000000004b54d4 in do_cfunc (c=0x802dbeb00, args=0x0, from_tty=1) at ./cli/cli-decode.c:67 #7 0x00000000004b8495 in cmd_func (cmd=0x802dbeb00, args=0x0, from_tty=1) at ./cli/cli-decode.c:1777 #8 0x00000000004542ac in execute_command (p=0x802c1e083 "", from_tty=1) at top.c:428 #9 0x000000000057d3de in command_handler (command=0x802c1e080 "") at event-top.c:499 #10 0x000000000057d9c2 in command_line_handler (rl=0x802d1e67c "run") at event-top.c:704 #11 0x0000000800d6b087 in rl_callback_read_char () from /lib/libreadline.so.8 #12 0x000000000057ca51 in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:177 #13 0x000000000057d2a9 in stdin_event_handler (error=0, client_data=0x0) at event-top.c:434 #14 0x000000000057b9fb in handle_file_event (data=...) at event-loop.c:831 #15 0x000000000057b072 in process_event () at event-loop.c:402 #16 0x000000000057b15b in gdb_do_one_event (data=0x0) at event-loop.c:467 #17 0x000000000057594f in catch_errors (func=0x57b090 <gdb_do_one_event>, func_args=0x0, errstring=0x781003 "", mask=6) at exceptions.c:521 #18 0x00000000004ccdf4 in tui_command_loop (data=0x0) at ./tui/tui-interp.c:172 #19 0x00000000005760c7 in current_interp_command_loop () at interps.c:291 #20 0x0000000000449791 in captured_command_loop (data=0x0) at ./main.c:228 #21 0x000000000057594f in catch_errors (func=0x449780 <captured_command_loop>, func_args=0x0, errstring=0x762a2f "", mask=6) at exceptions.c:521 #22 0x000000000044a6c7 in captured_main (data=0x7fffffffdb50) at ./main.c:936 #23 0x000000000057594f in catch_errors (func=0x4497d0 <captured_main>, func_args=0x7fffffffdb50, errstring=0x762a2f "", mask=6) at exceptions.c:521 #24 0x000000000044a751 in gdb_main (args=0x7fffffffdb50) at ./main.c:945 #25 0x00000000004494be in main (argc=2, argv=0x7fffffffdbc8) at gdb.c:44 closer inspection of b and it's origin in bs on line 4579 reveals bs actually points to a string instead of a struct with real pointers. No matter what dwarf the Go compiler generates, that should probably not happen. Compiling gdb without thread support makes the issue go away. Setting a breakpoint at main.main in the Go program, before running, seems to work around the problem, therefor i conclude it's likely due to an uninitialized bs_head variable.
If you enabled the THREADS option in the gdb port that added an extra patch with thread support using libthread_db that itself was somewhat buggy. It is quite possible that the error was in that patch rather than in gdb itself. Would you be able to retest with a more recent version of gdb (such as 7.11 or later) which includes a different implementation of thread support?