hints for debugging?

[Dorival Pedroso]

hi, i'm just wondering if anyone would have any hints/links for debugging go code? (gdb in linux without an ide would be great...)

[chris dollin]

On 27 June 2012 09:52, Dorival Pedroso <dorival...@gmail.com> wrote:
> hi, i'm just wondering if anyone would have any hints/links for debugging go
> code? (gdb in linux without an ide would be great...)

Write tests.
Keep the code simple.

Chris

--
Chris "allusive" Dollin

[Mikael Gustavsson]

On Wednesday, June 27, 2012 4:52:08 PM UTC+8, Dorival Pedroso wrote:

hi, i'm just wondering if anyone would have any hints/links for debugging go code? (gdb in linux without an ide would be great...)

I think this should answer your questions: http://golang.org/doc/gdb

I recently tried out debugging my go web app using command line gdb under OSX, I will paste below what I wrote down for myself and my team. It might be of interest to you or others:

Debugging go programs with gdb

-----------------------------------------------

Go apps can be debugged with gdb 7.1 and higher.

Sadly, if you're on os x you probably have gdb 6.x (or no gdb at all), check the version:

gdb --version

If you need to upgrade on OS X, download latest stable release source code from

http://sourceware.org/gdb/download/

Unpack and compile:

tar xjvf gdb-7.4.tar.bz2

cd gdb-7.4

less gdb/README

./configure

make

Copy the resulting gdb/gdb executable to a directory in your path which precedes your old gdb. Check that you see the right version:

hash -r

gdb --version

If on OS X, you have to allow gdb to inspect and control other running processes, follow the steps here to generate a code signing certificate for gdb:

http://sourceware.org/gdb/wiki/BuildingOnDarwin

Then you can apply the cert to gdb:

codesign -s gdb-cert /path/to/my/new/gdb

Now you can debug any of your go applications:

gdb myapp

Or if your go app needs root:

sudo gdb myapp

Load extra go functionality into gdb from your go installation:

gdb> source /path/to/go/src/pkg/runtime/runtime-gdb.py

Start your application:

gdb> run 

Pause your application with Ctrl-c, resume by typing "continue".

Add breakpoints to functions, methods or lines:

gdb> break myapp/models.LookupCity

gdb> break myapp/controllers.(*City).Search

gdb> break /Users/me/src/myapp/models/city.go:245

Remove breakpoints with clear:

gdb> clear /Users/me/src/myapp/models/city.go:245

List breakpoints:

gdb> info breakpoints

Delete breakpoint by number in info list:

gdb> delete 1

After adding breakpoints, type "run" or "continue" and wait for a breakpoint to trigger (perhaps by interacting with your app through a browser).

When a breakpoint has triggered, use bt to see a stack trace:

gdb> bt

And list to see the current code:

gdb> list

Use n to go to next line:

gdb> n

Or s to step into any function calls on the current line:

gdb> s

Use finish to step out of the current function:

gdb> finish

Use p to print the value of any local variable or argument:

gdb> p x

gdb> p city.Id

gdb> p *city       (to dereference a pointer to struct)

gdb> info locals

gdb> info args

Use up and down to move up and down in the stack trace to examine variables in calling functions:

gdb> up

gdb> p somevar

gdb> down

Use c (continue) to let the program continue running until another breakpoint is reached:

gdb> c

Note that if the goroutine you are stepping through is scheduled by the go scheduler to switch to another thread, then gdb might become confused. This can happen if you are trying to step past a line that reads from the database for example. To avoid this problem it seems it helps to use break instead of next. So if you are on line 23 and want to go to line 25, instead of typing 'n' two times, type 'break 25' and 'c'.

You can view a list of existing goroutines like this:

gdb> info goroutine

And view the stacktrace of any goroutine like this:

gdb> goroutine 1 bt

gdb> goroutine 2 bt

Finally, use ctrl-c and quit to exit

gdb> quit

[Dorival Pedroso]

Thanks a lot, Mikael!

This is certainly very useful.

Before I had tried to search for 'gdb' or 'debugging' within the search in http://golang.org/, but couldn't get an answer...

By using google (with 'golang gdb') I can find it.

Kind regards.

Dorival

[Archos]

I found this page[1] in the *first result* with the words "golang gdb"
but using bing.
Luckily there is life after of g oogle: Bing, Duck Duck Go, Wolfram,
Yahoo, ...

[1]: http://golang.org/doc/gdb

On Jun 28, 9:58 am, Dorival Pedroso <dorival.pedr...@gmail.com> wrote:
> Thanks a lot, Mikael!
> This is certainly very useful.

> Before I had tried to search for 'gdb' or 'debugging' within the search inhttp://golang.org/, but couldn't get an answer...

[Archos]

On Jun 28, 9:58 am, Dorival Pedroso <dorival.pedr...@gmail.com> wrote:

> Thanks a lot, Mikael!
> This is certainly very useful.

> Before I had tried to search for 'gdb' or 'debugging' within the search inhttp://golang.org/, but couldn't get an answer...

> By using google (with 'golang gdb') I can find it.

I though that you said that you cann't find it.

Well, it's very sane to know alternatives and use them :)

[jason]

awesome walkthrough!  I was curious if you knew a way to auto load the source file once you start gdb so you don't need to manually run it each time.

[Dorival Pedroso]

i've compiled a test with 'go test -c -N' but am still having troubles with 'info locals' (that don't show)... any hints? many thanks in advance. dorival

[minux]

On Sun, Jul 1, 2012 at 6:21 PM, Dorival Pedroso <dorival...@gmail.com> wrote:

i've compiled a test with 'go test -c -N' but am still having troubles with 'info locals' (that don't show)... any hints? many thanks in advance.

go test -gcflags "-N -l" -c somepkg

[Dorival Pedroso]

thank you very much!

it works now

[Dorival Pedroso]

Hi, I'm just wondering how to force symbols in dependent libraries (my own Go code in a parallel folder)? gdb cannot see 'locals' in a library... Cheers. Dorival

[Lunix Watt]

As far as I know, the libraries is compiled as an .a object, to be statically linked with the binary. All compilation step is already do, and this includes some optimizations. So, the only solution I see is to build library with the gcflags described above, build the binary with the same sets of flags and debug the program. But I'm not sure, I not created any package yet.

[minux]

On Mon, Aug 20, 2012 at 12:07 PM, Dorival Pedroso <dorival...@gmail.com> wrote:

Hi, I'm just wondering how to force symbols in dependent libraries (my own Go code in a parallel folder)? gdb cannot see 'locals' in a library... Cheers. Dorival

you can build a development version of dependent pkgs.

go install -a -v -gcflags "-N -l" pkgs

and then rebuild your test program.

[Dorival Pedroso]

thank you very much -- much appreciated! i can see those symbols now. cheers. dorival

[Abhijit Kadam]

This is good information. However many times I am not able to debug runtime C code. At some places it work and suddenly does not. Some information like 1) sys call execution, 2) scheduling 3) Machines thread info 

I tired:

go build -a -v -gcflags "-N -l" App.go

gdb ./App

(gdb) source ~/gosource/go/src/pkg/runtime/runtime-gdb.py

(gdb) source ~/gosource/go/src/pkg/runtime/

put a break point and then run

(bt doesn't give me c stack (proc.c)

(gdb) bt

#0  main.GetEmpList (~anon0= []main.Employee = {...}) at /home/abhijitk/gowork/src/App/App.go:124

#1  0x0000000000400fad in main.main () at /home/abhijitk/gowork/src/App/App.go:36

(gdb) info go routines

* 1  running runtime.gosched

* 2  syscall runtime.notetsleepg

Sometimes below command work and I get to see C code but most of the times it doesn't work

(gdb) goroutine 1 bt

Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x8: 

Error occurred in Python command: Cannot access memory at address 0x8

[Dave Cheney]

You probably need to rebuild the stdlib with -N to reliably step into the runtime. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Abhijit Kadam]

On Thursday, January 16, 2014 6:44:30 PM UTC+5:30, Dave Cheney wrote:

You probably need to rebuild the stdlib with -N to reliably step into the runtime. 

Can you please provide some leads(links)? I mean where can I find source. I use ubuntu 64 bit. 

[minux]

go install -a -v -gcflags "-N -l" std

then rebuild your program.

[Abhijit Kadam]

Thanks. I did that and it compiled all go libs. Then ran the debugger. How to find how many goroutines each OS thread is running. Also find the stack trace for OS thread. (to see goroutine stack I am using: "goroutine n bt" [n is the number for goroutine that I got from "info goroutines" command])

(gdb) info threads

  Id   Target Id         Frame 

* 1    LWP 8396 "App2"   main.main () at /home/abhijitk/gowork/src/App/App2/App2.go:18

(gdb) bt

#0  main.main () at /home/abhijitk/gowork/src/App/App2/App2.go:18

(gdb) info goroutines

* 1  running runtime.malg

* 2  syscall runtime.notetsleepg

  3 runnable main.func·001

(gdb) goroutine 3 bt

#0  main.func·001 () at /home/abhijitk/gowork/src/App/App2/App2.go:12

#1  0x0000000000415f70 in ?? () at /home/abhijitk/gosource/go/src/pkg/runtime/proc.c:1385

#2  0x0000000000000000 in ?? ()

(gdb) goroutine 3 frame 1

#1  0x0000000000415f70 in ?? () at /home/abhijitk/gosource/go/src/pkg/runtime/proc.c:1385

1385            schedule();

Python Exception <class 'gdb.error'> Frame is invalid.: 

Error occurred in Python command: Frame is invalid.

 

[Ian Lance Taylor]

On Thu, Jan 16, 2014 at 9:54 PM, Abhijit Kadam <abhij...@gmail.com> wrote:
>
> Thanks. I did that and it compiled all go libs. Then ran the debugger. How
> to find how many goroutines each OS thread is running.

I don't understand the questions. Each thread runs one goroutine at a
time. Goroutines can migrate between threads. What are really trying
to find out?

> Also find the stack
> trace for OS thread. (to see goroutine stack I am using: "goroutine n bt" [n
> is the number for goroutine that I got from "info goroutines" command])

You can see the stack trace for the thread using the usual gdb "bt"
command. gdb already understands threads.

>
> (gdb) info threads
> Id Target Id Frame
> * 1 LWP 8396 "App2" main.main () at
> /home/abhijitk/gowork/src/App/App2/App2.go:18
>
> (gdb) bt
> #0 main.main () at /home/abhijitk/gowork/src/App/App2/App2.go:18
>
> (gdb) info goroutines
> * 1 running runtime.malg
> * 2 syscall runtime.notetsleepg
> 3 runnable main.func·001
>
> (gdb) goroutine 3 bt
> #0 main.func·001 () at /home/abhijitk/gowork/src/App/App2/App2.go:12
> #1 0x0000000000415f70 in ?? () at
> /home/abhijitk/gosource/go/src/pkg/runtime/proc.c:1385
> #2 0x0000000000000000 in ?? ()
>
> (gdb) goroutine 3 frame 1
> #1 0x0000000000415f70 in ?? () at
> /home/abhijitk/gosource/go/src/pkg/runtime/proc.c:1385
> 1385 schedule();
> Python Exception <class 'gdb.error'> Frame is invalid.:
> Error occurred in Python command: Frame is invalid.

I think you are at the top of the goroutine stack--the point where the
goroutine was started. There is nothing to see.

Ian

[Abhijit Kadam]

On Friday, January 17, 2014 8:14:55 PM UTC+5:30, Ian Lance Taylor wrote:

On Thu, Jan 16, 2014 at 9:54 PM, Abhijit Kadam <abhij...@gmail.com> wrote:
>
> Thanks. I did that and it compiled all go libs. Then ran the debugger. How
> to find how many goroutines each OS thread is running.

I don't understand the questions.  Each thread runs one goroutine at a
time.  Goroutines can migrate between threads.  What are really trying
to find out?

 

Exactly, several are queued on each thread.  The custom command of the go gdb extension "info goroutines" gives just total number of routines or it gives the routines running on main os thread and we need to switch to another os thread using gdb to see goutines ran by that thread.

> Also find the stack
> trace for OS thread. (to see goroutine stack I am using: "goroutine n bt" [n
> is the number for goroutine that I got from "info goroutines" command])

You can see the stack trace for the thread using the usual gdb "bt"
command.  gdb already understands threads.

Yes, you see I did fire "info threads" & "bt" etc. and was expecting stack trace of os thread starting from runtime upto the go code and then go back into the frame that has runtime code to see the goroutine queue, syscall, etc. To see goroutine specific stack I guess I need to use "goroutine <number> bt" (provided by extension)

[Ian Lance Taylor]

On Fri, Jan 17, 2014 at 7:28 AM, Abhijit Kadam <abhij...@gmail.com> wrote:
>
> On Friday, January 17, 2014 8:14:55 PM UTC+5:30, Ian Lance Taylor wrote:
>>
>> On Thu, Jan 16, 2014 at 9:54 PM, Abhijit Kadam <abhij...@gmail.com> wrote:
>> >
>> > Thanks. I did that and it compiled all go libs. Then ran the debugger.
>> > How
>> > to find how many goroutines each OS thread is running.
>>
>> I don't understand the questions. Each thread runs one goroutine at a
>> time. Goroutines can migrate between threads. What are really trying
>> to find out?
>
>
>
> Exactly, several are queued on each thread. The custom command of the go
> gdb extension "info goroutines" gives just total number of routines or it
> gives the routines running on main os thread and we need to switch to
> another os thread using gdb to see goutines ran by that thread.

I see. If info goroutines only shows the goroutines attached to a
particular thread, that sounds like a bug in runtime-gdb.py.

>> > Also find the stack
>> > trace for OS thread. (to see goroutine stack I am using: "goroutine n
>> > bt" [n
>> > is the number for goroutine that I got from "info goroutines" command])
>>
>> You can see the stack trace for the thread using the usual gdb "bt"
>> command. gdb already understands threads.
>
>
> Yes, you see I did fire "info threads" & "bt" etc. and was expecting stack
> trace of os thread starting from runtime upto the go code and then go back
> into the frame that has runtime code to see the goroutine queue, syscall,
> etc. To see goroutine specific stack I guess I need to use "goroutine
> <number> bt" (provided by extension)

The stack is not set up as you describe--there is no runtime code that
manages the goroutine queue and calls into the Go code. If there
were, it would be really painful to block goroutines.

Ian

[Abhijit Kadam]

On Friday, January 17, 2014 9:07:58 PM UTC+5:30, Ian Lance Taylor wrote:

On Fri, Jan 17, 2014 at 7:28 AM, Abhijit Kadam <abhij...@gmail.com> wrote:
>
> On Friday, January 17, 2014 8:14:55 PM UTC+5:30, Ian Lance Taylor wrote:
>>
>> On Thu, Jan 16, 2014 at 9:54 PM, Abhijit Kadam <abhij...@gmail.com> wrote:
>> >
>> > Thanks. I did that and it compiled all go libs. Then ran the debugger.
>> > How
>> > to find how many goroutines each OS thread is running.
>>
>> I don't understand the questions.  Each thread runs one goroutine at a
>> time.  Goroutines can migrate between threads.  What are really trying
>> to find out?
>
>
>
> Exactly, several are queued on each thread.  The custom command of the go
> gdb extension "info goroutines" gives just total number of routines or it
> gives the routines running on main os thread and we need to switch to
> another os thread using gdb to see goutines ran by that thread.

I see.  If info goroutines only shows the goroutines attached to a
particular thread, that sounds like a bug in runtime-gdb.py.

No, not that, I put it in a wrong way. I was rather asking if it is so (probably not). Also if not then how do we determine that.

>> > Also find the stack
>> > trace for OS thread. (to see goroutine stack I am using: "goroutine n
>> > bt" [n
>> > is the number for goroutine that I got from "info goroutines" command])
>>
>> You can see the stack trace for the thread using the usual gdb "bt"
>> command.  gdb already understands threads.
>
>
> Yes, you see I did fire "info threads" & "bt" etc. and was expecting stack
> trace of os thread starting from runtime upto the go code and then go back
> into the frame that has runtime code to see the goroutine queue, syscall,
> etc. To see goroutine specific stack I guess I need to use "goroutine
> <number> bt" (provided by extension)

The stack is not set up as you describe--there is no runtime code that
manages the goroutine queue and calls into the Go code.  If there
were, it would be really painful to block goroutines.

Ian

ok, I need to do more study.