Debugging in Go seems to be a very difficult task to accomplish

[Meir]

This is my first experience of debugging in Go. I am trying to debug this code: http://play.golang.org/p/8WxRtpWgk- (it implements, so far incorrectly, a generic puzzle solver with an application to the Pancake puzzle).

I use gdb (have not heard of a better tool for Go, but please tell me if there is one). In particular, I would like to step through the makeTestState() function that starts on line 47 and is called from main(). I am experiencing the following:

1. If I put a breakpoint at main(), it takes four(!) "step over" commands to get to the next line. This does not seem right.

2. If I use "step into", I am frequently taken into some code not of my writing -- certainly not the function that I wanted to step into...

3. Lastly, I am not able at all to step into makeTestState(). I am guessing that it ends up being inlined, which is totally undesirable for debugging. Is there a compilation mode whereby optimizations that interfere with debugging are turned off?

[peterGo]

Meir,

The state of gdb support
https://groups.google.com/d/msg/golang-nuts/DS5ZGswXC68/4kBgwVaAApYJ

Peter

[chris dollin]

On 3 April 2014 19:26, Meir <mgol...@gmail.com> wrote:

This is my first experience of debugging in Go. I am trying to debug this code: http://play.golang.org/p/8WxRtpWgk- (it implements, so far incorrectly, a generic puzzle solver with an application to the Pancake puzzle).

I use gdb (have not heard of a better tool for Go, but please tell me if there is one).

Debugging need not necessarily involve a special tool called

a "debugger".

Unit tests and print statements are generally useful.

Chris

--
Chris "allusive" Dollin

[Meir Goldenberg]

(1) Does "generally useful" imply "convenient and sufficient"?

(2) Unit tests are not an invention of Go. Nonetheless, solid debugging tools exist for other languages. In particular, good IDEs make sure to provide strong debugging capabilities. I believe that there are good reasons for that.

(3) In particular, unit tests do not help with debugging a function that implements a really intricate algorithm, especially one that involves recursion (think of adversarial search with Alpha-Beta pruning)...

[Rodrigo Kochenburger]

Pass -gcflags "-N -l" to go build, as specified at http://golang.org/doc/gdb.

- RK

--
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/d/optout.

[Meir Goldenberg]

This did the trick -- the function does not get inlined!

Can I somehow make liteide use this option?

[Rodrigo Kochenburger]

Sorry, I can't help w/ liteide. I never used it.

- RK

[Dan Kortschak]

... or to paraphrase Monty Python:

What's wrong a print statement, boy? Hmm? Why not start her off with a nice print? You don't have to go leaping straight for the debugger like a bull at a gate. Give it a print, boy.

[Shawn Milochik]

To further that:

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

    -- Brian Kernighan, "Unix for Beginners" (http://en.wikiquote.org/wiki/Brian_Kernighan)

[egon]

Just to add some more appropriate quotes:

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

  -- C.A.R. Hoare

Simplicity is prerequisite for reliability.

  -- Edsger W. Dijkstra

I definitely suggest doing this challenge/exercise: http://www.carlopescio.com/2011/06/cut-red-wire.html

TL;DR; pick a problem, write code for it and it must work the first time, otherwise you have failed the challenge.

This means no trying out concepts, no test-runs, no testing language features etc.

You are allowed to compile only once for the challenge.

+ egon

[Henrik Johansson]

The importance of the quotes above cannot be overstated.

That aside and that I like print statements there has been a few times when I wanted better debugging.

I do it too seldom I am sure but having break points that only trigger depending on certain conditions can be really neat.

--

[Dan Kortschak]

On Fri, 2014-04-04 at 01:14 +0200, Henrik Johansson wrote:
> I do it too seldom I am sure but having break points that only trigger
> depending on certain conditions can be really neat.

This can also be done within language since recompilation is so fast -
conditional reporting (or other behaviour) does exactly what is wanted
here. At the moment I'm debugging a very complicated (because of input
data type and scale) problem - graphical representation is the only way
I can see what is going on. No debugger will help me with that.

[Bakul Shah]

On Thu, 03 Apr 2014 19:46:22 BST chris dollin <ehog....@googlemail.com> wrote:
>
> On 3 April 2014 19:26, Meir <mgol...@gmail.com> wrote:
>
> >
> > This is my first experience of debugging in Go. I am trying to debug this
> > code: http://play.golang.org/p/8WxRtpWgk- (it implements, so far
> > incorrectly, a generic puzzle solver with an application to the Pancake
> > puzzle).
> >
> > I use gdb (have not heard of a better tool for Go, but please tell me if
> > there is one).
> >
>
> Debugging need not necessarily involve a special tool called
> a "debugger".

A debugger is essentially a visualization tool.

> Unit tests and print statements are generally useful.

So are these.

But a good debugger (such as the long extinct "ups" debugger)
can really help you "see" the dynamic behavior of a program
better. If you didn't write a program but you have to
fix/maintain/ehance it, all the programming pearls by great
computer scientists won't help you as much as a debugger
would! [It is particularly useful for programs in O-O
languages that encourage you to chop up structures and behavior
in little pieces and bury them in N different files!]

[David Skinner]

I find gdb adequate for the few times I use it.

When I was debugging a recursive function which did not work correctly the first time, I used this method. To test a simple case that I could manually calculate the correct answers and verify my sometimes faulty logic. It has the advantage of providing a printout of intermediate results which are now archived for posterity and will only show up if something breaks. Of course, I did not know that I was entirely successful until a saw the sphere on the screen.

// sphere_test.go

package senet

import (
"azul3d.org/v0/scene/geom"
"fmt"
)

func ExampleSphere() {
ball := Sphere(1, geom.Static)
fmt.Printf("ball := %v\n", ball)
fmt.Printf("Vertices := %v\n", ball.Vertices)
fmt.Printf("Indices := %v\n", ball.Indices)
fmt.Printf("TextureCoords := %v\n", ball.TextureCoords)
// Output:
// ball := Mesh(Static, Hidden=false, 10 Vertices)
// Vertices := [{0.57735026 0.57735026 0.57735026} {0.57735026 -0.57735026 -0.57735026} {-0.57735026 0.57735026 -0.57735026} {-0.57735026 -0.57735026 0.57735026} {1 0 0} {0 0 -1} {0 1 0} {-1 0 0} {0 0 1} {0 -1 0}]
// Indices := [0 4 6 1 4 5 2 5 6 4 5 6 0 6 8 2 6 7 3 7 8 6 7 8 0 8 4 3 8 9 1 9 4 8 9 4 1 5 9 2 5 7 3 7 9 5 7 9]
// TextureCoords := [[{0.38831162 0.69591326 1 1} {0.20114458 0.30408671 1 1} {0.6116884 0.30408671 1 1} {0.7988554 0.69591326 1 1} {0.25 0.5 1 1} {0.5 0 1 1} {0.5 0.5 1 1} {0.75 0.5 1 1} {0.5 1 1 1} {0 0.5 1 1}]]
//

}

[Andrew Gerrand]

I have found debuggers most useful to examine the interactions between different pieces of code; the places where it is hard to write good unit tests.

But IMO there is no real substitute for some considered print statements. And Go gives you some nice tricks for printing state at opportune times. For example, over the years I have written this in various forms:

type logReader struct {

  prefix string

  io.Reader

}

func (r logReader) Read(b []byte) (int, error) {

  n, err := r.Reader.Read(b)

  log.Printf("%v Read(%x) == (%v, %v)", r.prefix, b, n, err)

  return n, err

}

That lets you wrap any io.Reader r with logReader{"some label", r} to get some visibility into what's going on. It gets even more interesting when you wrap a type with more methods. I'm not sure how applicable this suggestion is to your particular problem, but maybe it will help others who come across this thread.

I don't wish to downplay the importance of a good debugger. I think we will have one for Go and it won't be gdb (the model is wrong). I don't know when that will be, though. I hope gdb is good enough for you today.

Andrew

[Meir Goldenberg]

I see from this comment:

"[[it is particularly useful for programs in O-O

languages that encourage you to chop up structures and behavior

in little pieces and bury them in N different files!]]"

that I do not understand something very important about software design with Go. Could you please explain why and how Go is different? Aren't structures and interfaces scattered among many file in Go as well?

[Hotei]

OP- Aren't structures and interfaces scattered among many file in Go as well? 

Structures possibly - depending on your coding style.  Interfaces not so much.  One of the nice things about go is that you don't have to tell the compiler that something satisfies an interface.  Once you define your interface (in one place) the compiler figures out what types meet it and if they do - you can just use them.  Takes a little getting used to if you're coming from the C++ world but in practice its a really useful feature.

[Nate Finch]

Small functions with predictable output that are easily unit tested are your best friend in go.  Of course, there's always a possibility of a bug happening one level up where you combine the small methods, but it is less common and usually pretty obvious when you know all the small functions work correctly.  This especially true of relatively simple applications that just implement a know algorithm.

On Thursday, April 3, 2014 2:26:46 PM UTC-4, Meir wrote:

[Meir Goldenberg]

On Fri, Apr 4, 2014 at 3:07 PM, Hotei <hote...@gmail.com> wrote:

OP- Aren't structures and interfaces scattered among many file in Go as well? 

Structures possibly - depending on your coding style.  Interfaces not so much.  One of the nice things about go is that you don't have to tell the compiler that something satisfies an interface.  Once you define your interface (in one place) the compiler figures out what types meet it and if they do - you can just use them.  Takes a little getting used to if you're coming from the C++ world but in practice its a really useful feature.

Hmm... Doesn't this feature make the code harder to understand? I mean, if you have an implicit indication that a type implements a certain interface, then everything is clear. Now I have to look for definition of interfaces that my type implements... BTW, where would interface definitions usually fit?

[Aram Hăvărneanu]

I'm only using debuggers when I need to debug the assembly. That means
either assembly that I've written, or C code that doesn't work
correctly. I never use the source-level debugging mode, it only slows
me down. My favorite debugger is Plan 9's acid. Being an actual
programming language, it is easy to implement walkers for the data
structures I need. My second favorite debugger is Solaris's mdb. It's
not quite a real programming language, but it has a very consistent
model and it support pipes. Creating walkers unfortunately means
writing C, but I am a programmer.

I really hate gdb, but it's the most common and sometimes it's all I
got. I just use it, complaining about it wouldn't solve my problems.

I don't use debuggers quite that often, because most of the time I
don't have to debug assembly. Then I just use tracing to debug my Go
code. Debug prints is the most primitive tracing technique, but it's
probably also the most useful. It's very easy and results can be
shared with other people. I also use DTrace for tracing. Using it for
Go code means understanding the difference between Go calling
convention and the System V ABI, but as I already mentioned, I am a
programmer. I believe more people should embrace dynamic tracing. If
you use Linux try ktap and perf and use this as a reference:
https://github.com/brendangregg/dtrace-cloud-tools/tree/master/go

I find Go vastly easier to debug than C.

--
Aram Hăvărneanu

[Nate Finch]

You shouldn't ever look for interfaces you implement.  Instead, look for functions that do what you want, and make your type implement the interface they take.

[Meir Goldenberg]

Still where do you usually put the definitions of the interfaces?

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/YG-APRPwkZc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Hotei]

The fact that it "sounds" hard seems to indicate that you haven't tried to use interfaces yet.  Experiment a little with them and I think you'll find it much easier to understand.  Loosely translated into "computer-speak" it means that if someone else has written a program that operates on a "foo" with methods x,y and z - then if you can make your "bar" also have x,y and z methods that means you can now use code the other person has written for "foo" without _explicitly_ having "foo" know anything about "bar".  It actually makes code _easier_ to understand because if you know how to use one tool and another tool "works the same way", you can switch tools without any extra code to glue them together.

I must admit the only problem I have is that it's sometimes not easy to know which interfaces your "bar" will match when dealing with code other than one's own. Years ago when I asked that question (in relation to displaying interface matches using godoc) I was told it was not feasible since some interfaces match too many types to list.  In practice lack of that facility it hasn't been a problem.

As to where interface definitions fit - what works for me is when I have a package of stuff that operates with a specific interface I put the interface definition in that source file.  If the interface is tiny it might all go in the main file.

On Friday, April 4, 2014 8:19:26 AM UTC-4, Meir wrote:

[Nate Finch]

Put the definition of an interface near the function(s) that use it.  Where specifically is up to personal taste.  I wouldn't really worry about multiple files and stuff spread over files, as long as there's some sort of logical grouping so you can find what you need when you need it.  It's just better than the languages where things *have* to all be in separate files.

[oju...@gmail.com]

1 - Open your project in LiteIDE

2 - Select "Build" menu and under it select "Build Configuration..."

3 - A dialog shows up. Select "Custom" tab. It contains a list of key/value pairs

4 - Double click the space reserved for the value of "BUILDARGS"

5 - write -gcflags "-N -l"

6 - close the dialog by clicking Ok button

7 - rebuild your project (Ctrl+B)

8 - press F5 to start debugging

9 - put some breakpoints wherever you wish

10 - press f5 again to reach the first breakpoint

From there you can inspect variables, call stack, etc.

[Aram Hăvărneanu]

On Fri, Apr 4, 2014 at 6:34 PM, <oju...@gmail.com> wrote:
> -gcflags "-N -l"

There should't be any need of this for most Go programmers. Go
programs can be debugged as is, there's no need for special settings.
Flags like -N and -l can be useful in certain circumstances, but we
certainly don't want to encourage people to blindly apply them by
default. Remember that if you're not debugging the binary you put into
production, you're probably debugging the wrong thing,

--
Aram Hăvărneanu

[ehedgehog]

On Thursday, April 3, 2014 7:58:37 PM UTC+1, Meir wrote:

(1) Does "generally useful" imply "convenient and sufficient"?

It means that in many cases it is useful, and that this general utility
is not confined to debugging.

Whether or not it is "sufficient" depends on one's preferences for
sufficiency and the kinds of problems one is trying to crack.

(2) Unit tests are not an invention of Go.

Yes ...

Nonetheless, solid debugging tools exist for other languages. In particular, good IDEs make sure to provide strong debugging capabilities. I believe that there are good reasons for that.

Maybe there are. That doesn't mean you /must/ use a "debugger" to do debugging; one is
not crippled by debuggerlessness. Which was the point of my original reply.

 
(3) In particular, unit tests do not help with debugging a function that implements a really intricate algorithm, especially one that involves recursion (think of adversarial search with Alpha-Beta pruning)...

Well, I don't think I believe your premise, but even if I grant it, it's not clear to me that using
a debugger is going to help much either.

I'm not saying one /shouldn't/ use a debugger.

Chris

[Am Laher]

Andrew, 

 

I think we will have one for Go and it won't be gdb (the model is wrong). I don't know when that will be, though. 

Any more hints about this potential future Go debugger of which you speak? 

I guess a debugger is a debugger is a debugger, but do you know anything about the project so far?

I appreciate it's optimistic to expect more info, but e.g. it would be cool to see something like Chronon (replays entire application in exact sequence), or the ability to see allocation of goroutines onto threads.

Cheers

[Sam Harwell]

Unit tests are extremely important, but they are not “debugging”.

 

If you are using print statements to debug, then either you are doing something wrong, or you are working around something that the language creator did wrong/overlooked. In the case of Go, we are currently stuck due to the latter. With a proper debugger, print statements for nearly all debugging purposes are obsolete because you can attach to a running process and insert a tracepoint (breakpoint that prints a message at a specific location and continues execution rather than halting) without recompiling the code or even relaunching the application.

 

Sam

 

From: golan...@googlegroups.com [mailto:golan...@googlegroups.com] On Behalf Of chris dollin
Sent: Thursday, April 3, 2014 1:46 PM
To: Meir
Cc: golang-nuts
Subject: Re: [go-nuts] Debugging in Go seems to be a very difficult task to accomplish

 

On 3 April 2014 19:26, Meir <mgol...@gmail.com> wrote:

This is my first experience of debugging in Go. I am trying to debug this code: http://play.golang.org/p/8WxRtpWgk- (it implements, so far incorrectly, a generic puzzle solver with an application to the Pancake puzzle).

I use gdb (have not heard of a better tool for Go, but please tell me if there is one).

 

Debugging need not necessarily involve a special tool called

a "debugger".

Unit tests and print statements are generally useful.

Chris

--
Chris "allusive" Dollin

--

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.

[Dan Kortschak]

Print statements do something that a debugger will rarely be able to do
without significant scripting, at which point you may as well use the
language; they can format the data into some form that is more readily
digestible. Debuggers do a good job at close focus, but are very poor at
giving broad structure debugging information.

[Hotei]

Debuggers can be useful - I'll admit that.  When I wrote in C and later in C++ they were very welcome tools.  However - in go - I find that most problems never rise to the level of _needing_ a debugger.  In 99 times out of 100 a simple print statement in the right place is sufficient to show me what's wrong.   At some point the go team's focus may change and we'll get a debugger -  but meanwhile I don't feel "stuck" - I can be productive without one. And I think it's worth waiting for it to be done "right".  The go teams record of making good decisions stands on its own and I trust them with this one.

[Ian Dawes]

And careful debug logging has two very significant benefits that you'll almost never get from a debugger:

1) it forces you to think very carefully about how to write predictable code, so that you can decipher what happened from a debug log file.

2) it captures state when the problem happens, instead of when you happen to show up, which can be a lifesaver for hard to reproduce problems.

--- Ian

[Øyvind Teig]

Debugging with goroutines and channels is particularly interesting. I assume such a functionality is (like) 45 deg orthogonal with printlines.

When I worked with the occam debugger on transputers (in the early nineties) one could follow a channel from one process to the other. That was nice, and since occam was a language with distributed or shared memory model in the bottom, one could all of a sudden find oneself single-stepping on another processor. It was quite impressive.

In the early eighties I worked with the MPP Pascal (Micro Processor Pascal) debugger from Texas Instruments. The language was built on the world's first (?) concurrent language, Concurrent Pascal by Per Brinch Hansen (around 1975). The debugger would let me see the context (and stop on any line) in any concurrent process. Even instance "n" of an array of equal processes (give me 90% confidence on the last matter). It also had a control language, enabling me to "build my own" debugger.

The only problem I remember with the occam on transputer debugger was that it couldn't follow a channel that was not "connected" (in an ALT/select or input/output, I don't remember how that was treated if it were waiting for a timeout or an EVENT/hw/sw interrupt). I assume this would be a basic problem for Go as well. I don't think occam-pi has a debugger. Both occam-pi and Go would have sending channels over channels, making this even more complex. To support all this in a debugger would be a challenge.

If I were to write a debugger I would have used the fact that channels have scope out of the goroutines. They are global handles for safe (if used correctly) access of shared data. The scheduler knows about all of them; but not before they are created. But I would like to have a breakpoint when there is data on a channel (presented, waited for or sent) if it's not in scope yet. And it shall never become "optimized away" as my present debugger often brushes me off with.

But a Go debugger should enable me to see the world from the scheduler as well as from the code. 

I recommend that the Go debugger designers look into older concurrent debuggers as well. Some of the early designers were very smart.

/Øyvind

[Andrew Gerrand]

On 6 April 2014 15:37, Am Laher <a...@laher.net.nz> wrote:

Any more hints about this potential future Go debugger of which you speak? 

If I did I would say so. :-)

 

I guess a debugger is a debugger is a debugger, but do you know anything about the project so far?

I don't think "a debugger is a debugger," let alone "a debugger." I think there's plenty of room for innovation there.

Andrew

[Nyah Check]

Hi Gophers,

I know this post is old and there's a lot online with different sometimes contrasting opinions on how to debug go programs. My question given the complexities involved in multi-threading in Go does the go team have any plans on creating a standard debugger. I'm currently looking at delve and gdb(although inadequate). What's the best way of debugging go programs so far. I know some may say use intelligently placed fmt.Printf() statements. Just looking for more ideas.

Thanks,

Nyah

[Rob Pike]

Debugging is always hard, debuggers help, and better debuggers help more. I have had good luck with delve, myself. Perhaps if you explained the problem you're having there would be suggestions to make your task easier.

-rob

--

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+unsubscribe@googlegroups.com.

[Nyah Check]

Hi Rob,

I'm currently writing some documentation on how to Debug Docker binaries; given the fact that it's a large project gdb doesn't seem adequate for a newbie looking to contribute to the Docker project. Most Gophers I've talked to have recommended delve as the debugger to go with such cases. Just looking for other options.

Thanks,

Nyah

--

"The heaviest penalty for declining to rule is to be ruled by someone inferior to yourself." --Plato