gdb 7.3.1 Buss error 10

[senior7515]

Hello,

Every time I try to run gdb I get a buss error 10.

the program is as simple as a hello world.

package main

func main() {
println("helloworld")
}

I've tried to load the runtime-gdb.py correctly. It loads it.

The problem is that every time I run it it crashes with a Buss error
10.

On a freebsd 9.0 amd64, latest weekly build for go.

Any tips ?

Note: When it loads i see the correct Dwarf symbols message show up.
like this : Reading symbols from <program>.... done.

Any tips? I'm not very experienced gdb user, but I can successfully
debug on my mac with the same gdb version.

Kindly let me know if I can provide more details.

[senior7515]

2 Things worth updating the thread. 

1. Yes I built gdb from source with python support

2. If I simply do gdb. then source $GOROOT/src/pkg/runtime/runtime-gdb.py i get this error 

  File "/usr/local/go/src/pkg/runtime/runtime-gdb.py", line 23, in <module>

    goobjfile = gdb.current_objfile() or gdb.objfiles()[0]

IndexError: list index out of range

[senior7515]

I thought I would mention that I *can* debug c++ programs. 

This leads me to think that it's something related to go. 

Any tips? Thanks alot :)

[Andrew Gerrand]

Which version of gdb?

[Rob 'Commander' Pike]

On Jan 29, 2012, at 2:54 PM, Andrew Gerrand wrote:

> Which version of gdb?

Perhaps 7.3.1?

-rob

[Andrew Gerrand]

Ah, apologies. I scanned the body of the message for the version
number, missing the subject entirely.

Andrew

[senior7515]

Anything else I can provide besides the version? Let me know. 

[lvd]

do you have a go program loaded in gdb when you run runtime-gdb.py?  if not, that explains why gdb.objfiles() is empty.

the solution would be to run gdb with the binary to be debugged 

   gdb 6.out

and do the manual loading of runtime-gdb.py then.  the manual loading is a workaround for a bug, whose fix is pending, that doesn't let gdb find the script in macho binaries.  I'll make it say something helpful if this happens.

/Luuk

[lvd]

re-reading this thread, the python error seems unrelated to the bus error.  how did you get the bus error?

[lvd]

also, manual loading should only be neccesary on darwin. if runtime-gdb.py does not autoload on freebsd for you, could you send me a copy of a small binary that triggers the bug?

[senior7515]

I think there is a problem posting binaries to the mailing list. Here is a link to the binary file. 

http://ge.tt/8pNfLyC?c

MD5 (web.tar.gz) = f6e4307fbcb97f1f538ecb22f27be651

1. I was advised to build gdb with python support on IRC. This should not matter since I built it with (thread)?(xml)?(Thread)?(python)?. 

2. See problematic file attached. 

Note: though I didn't test very much the problem occurs the moment I use the http pkg. I did a simple `package main; func main() {println("helloworld");}` and it works.  

[lvd]

On Jan 31, 5:03 am, senior7515 <gallego.al...@gmail.com> wrote:
> I think there is a problem posting binaries to the mailing list. Here is a
> link to the binary file.

thanks. i'll have a closer look. first i'll go find a freebsd 9
machine.

>
> http://ge.tt/8pNfLyC?c
>
> MD5 (web.tar.gz) = f6e4307fbcb97f1f538ecb22f27be651
>
> 1. I was advised to build gdb with python support on IRC. This should not
> matter since I built it with (thread)?(xml)?(Thread)?(python)?.

the python support is only necessary for the pretty printers in pkg/
runtime/runtime-gdb.py, which on all ELF platforms, including FreeBSD,
should be loaded automatically by recent enough gdb's that have python
compiled in.

without loading it, or without python support in gdb, you should still
be able to use gdb with 6g output, but you'll see the C structures
underlying the Go types in the runtime.

so do you also get the bus error if you do gdb 6.out and run the
program without manually loading runtime-gdb.py?

do you ever get the bus error if you run the program outside of gdb?

[lvd]

reproduced, filed issue to keep track.

it's unrelated to the pretty printing, setting a breakpoint at the
start of main, running till there and then continuing works fine with
this test program.

the autoloading of the pretty printers turns out to be broken since
runtime_defs.go was renamed. a fix for that is pending.

gdb'ing gdb itself with the generated core dump tells it crashed on
breakpoint.c:4579, a line reading switch(b->type), involving a pointer
with a bogus value.

looks like a gdb internal problem, but i'll investigate it later.

/Luuk

[lvd]

reproduced, filed issue http://code.google.com/p/go/issues/detail?id=2818

[senior7515]

On Tuesday, January 31, 2012 2:02:49 AM UTC-5, lvd wrote:

On Jan 31, 5:03 am, senior7515 <galleg...@gmail.com> wrote:
> I think there is a problem posting binaries to the mailing list. Here is a
> link to the binary file.

thanks.  i'll have a closer look.  first i'll go find a freebsd 9
machine.

>
> http://ge.tt/8pNfLyC?c
>
> MD5 (web.tar.gz) = f6e4307fbcb97f1f538ecb22f27be651
>
> 1. I was advised to build gdb with python support on IRC. This should not
> matter since I built it with (thread)?(xml)?(Thread)?(python)?.

the python support is only necessary for the pretty printers in pkg/
runtime/runtime-gdb.py, which on all ELF platforms, including FreeBSD,
should be loaded automatically by recent enough gdb's that have python
compiled in.

Hi Luuk, 

I'm not sure this is correct. I built my gdb wihtout thread and it works with the http pkg which is what i'm trying to debug so I'm happy. 

Without manually loading it I can't do 

$info goroutines

Here is some copy/paste. 

(gdb) info goroutines

Undefined info command: "goroutines".  Try "help info".

(gdb) source /usr/local/go/src/pkg/runtime/runtime-gdb.py

Loading Go Runtime support.

(gdb) info goroutines

* 1  running runtime.gosched

  6  waiting runtime.gosched

* 4  syscall runtime.entersyscall

  5  waiting runtime.gosched

  9  waiting runtime.gosched

  13  waiting runtime.gosched

  12  waiting runtime.gosched

* 14  running runtime.entersyscall

(gdb) 

Hope this helps with debugging.