<p>It seems that gdb doesn't work with golang. So what is the best debugger to use for developing golang apps? </p>
<hr/>**评论：**<br/><br/>sethammons: <pre><p>fmt.Sprintf(). I wish I was joking. I've used flags and tags to turn on and off debug statements ala <a href="http://dave.cheney.net/2014/09/28/using-build-to-switch-between-debug-and-release">this post</a> from Dave Cheney.</p>
<p>I've heard that <a href="https://github.com/derekparker/delve/">Delve</a> is gaining some traction. And <a href="https://github.com/mailgun/godebug">MailGun</a> put out an interesting approach. I've not played with either much. If you find them useful, let me know!</p></pre>robertmeta: <pre><p>As someone who has been doing heavily threaded apps for going on 20 years -- log based debugging has long been my only true and trusted friend. Debuggers just tend to suck with concurrency (and that is minor concurrency, dozens of threads, not millions of goroutines) -- so does logging, but less.</p>
<p>The amount of money I have spent on "premium" debuggers supposed to "make debugging threaded code easy" over the last two decades is insane -- and I always returned to 'I will just log it'. </p>
<p>At this point I can't tell if it is Stockholm Syndrome or not -- but I find debuggers generally are far too costly to use (time wise, effort wise) and have a very poor return on investment.</p>
<p>The only thing that I have changed in the last decade is from mostly unstructured text logging to mostly structured logging in accessible formats (json, xml, etc). </p></pre>tech_tuna: <pre><p>Interesting, why do you use structured logging formats?</p></pre>bobappleyard: <pre><p>I use them because it's easier to build up context in sophisticated ways.</p>
<p>Your typical logging package might print out the function, line, time and an arbitrary message.</p>
<p>Well what if I also wanted to know, say, what database I was connected to, or what HTTP request I was serving? I can push that into the logging context and it pops out along with whatever messages I log in that context.</p>
<p>Combined with something like graylog, which allows you to search and filter on those fields, it can get really powerful</p></pre>tech_tuna: <pre><p>Would you happen to have a code sample you could share? Are you using existing libraries to do this or rolling your own, or both? Thanks.</p></pre>bobappleyard: <pre><p>Nothing public, that might change. Have a look at <a href="https://structlog.readthedocs.org/en/stable/" rel="nofollow">this</a>, which is where I got the idea from.</p></pre>tech_tuna: <pre><p>Cool, thanks.</p></pre>robertmeta: <pre><p>It lets you dump easier to parse and more data rich formats (trees of stuff, specific datatypes, etc). Just the other day I had to run a one off data recovery bit of code on a node, few hundred lines of code doing something rather trivial with two DBs.</p>
<p>I dumped the logs using <a href="https://github.com/Sirupsen/logrus" rel="nofollow">https://github.com/Sirupsen/logrus</a> in json output mode. Just a boring "the facts" sort of log, few million rows of (changed X to Y related changes changed A to B and C to D and E to F).</p>
<p>Couple days later -- it came back we had missed another table related to the X to Y change (but only where A = "value"), so I just did an ioutil read of the json and a decode into a structure and started looping over related chunks of data, and since they all lived in a single json object, it was profoundly easy -- took a few minutes to write. </p></pre>vxd: <pre><p>+1 to Mailgun's godebug. It's a little non-traditional, but it's saved me some frustration at least a few times.</p></pre>ifonefox: <pre><p>This one is cool:</p>
<p><a href="https://github.com/mailgun/godebug">https://github.com/mailgun/godebug</a></p></pre>thockin: <pre><p>Sadly, there is no good debugger after years. It is sort of pathetic.</p></pre>robertmeta: <pre><p>Point me to a great debugger for highly concurrent apps in any language, I would love to see one. (note: this is a serious request, 20 years seeking one, I have tried dozens). </p></pre>thockin: <pre><p>I didn't say great, I said good. Just GDB basics would be a huge improvement. </p></pre>robertmeta: <pre><p>You can sort of use it on Go code (either gccgo or standard) and it sort of works on mostly uselessly trivial code -- the problem is it doesn't understand all the specific internals... and -- as every debugger I have ever used -- is useless with concurrency.</p>
<p>As for "basics" -- what does that mean? breaks points... stepping... what? The problem is most real go code is likely to have concurrency, hundreds of goroutines as a floor, and millions isn't that unusual. How do you debug a million goroutines with a debugger -- heck, how do you do 900? Those 900 are mapped across X hardware threads applied to Y cores. Debuggers just don't seem to scale well to lots of little things running at the same time.</p>
<p>Logs work because they are highly tool friendly -- dump the logs as something like json, filter, filter, filter, parse, puzzle, replay... and that tooling you write can be reused, because the truth is -- a lot of concurrent bugs pop up occasionally, not every run, so even if you were willing to step through 900 goroutines -- you might not even find the issue on that run. </p>
<p>Honestly -- if Go is the first one to crack this problem I will be delighted, but I don't have high hopes. I suspect the reason we don't have a "Go debugger" yet is -- it would be as worthless as all the other debugger for concurrent code. </p></pre>thokk: <pre><p><a href="http://www.roguewave.com/products-services/totalview" rel="nofollow">TotalView</a> always seemed to work quite well, although I've not used it in several years. </p>
<p>A short overview of debugging threaded code using TotalView <a href="https://computing.llnl.gov/tutorials/totalview/part3.html" rel="nofollow">link</a></p>
<p>edit: added overview comment and link</p></pre>robertmeta: <pre><p>Thanks for the recommendation. I have actually purchased TotalView in the past -- it was "meh" to me as product, solid by not standout, and the licensing model was painfully complex based on developers, processes/cores (and weird caps on threads) -- has something changed recently that I should be awre of?</p></pre>thokk: <pre><p>Yup, the licensing is convoluted, it's expensive, the UI is clunky, and the tool itself is a bit complex to use, but we (devs at work) found it worked extremely well for debugging multithreaded apps - then again it may have been that our use case happen to fit in nicely with the tool.</p></pre>robertmeta: <pre><p>Yeah, it appears it hasn't changed too much recently. Still only allows real debugging of highly concurrent code on the team enterprise edition. They gate prices on so many things ... machine / developer / core / threads / processes -- it is labyrinthine. Our newest installed box has 144 hardware threads (4x 18 core[*2 HT] Xeons).</p>
<p>I remember it as a solid "par" -- a lot of the same problems and features of the competitors in the space. </p></pre>thokk: <pre><p>We were debugging just 2/4 processors with 2/4/8 cores per processor, so nothing close to what you're dealing with.</p>
<p>Would you mind listing a couple of the other debuggers you've used that you think might be worth looking at? </p></pre>robertmeta: <pre><p>Again, I basically hate all of them and use structured logging instead -- so I am not the best person to ask. That said Allinea and TotalView where the two that I remembering making me want to kill myself the least -- but still never bridging the cap into "better than logging". </p></pre>arechsteiner: <pre><p>IntelliJ is working on making the Go plugin for IDEA "production quality", including source-level debugging, by August 2015. I can't say if the current release already has good debugging functionality:</p>
<p><a href="https://github.com/go-lang-plugin-org/go-lang-idea-plugin" rel="nofollow">https://github.com/go-lang-plugin-org/go-lang-idea-plugin</a></p>
<p>LiteIDE also has debugging: </p>
<p><a href="https://github.com/visualfc/liteide" rel="nofollow">https://github.com/visualfc/liteide</a></p>
<p>I understand you're looking for a debugger, not an IDE (I hear Go developers are not very fond of IDEs ;), but since both are open source, maybe you could try to find out how they deal with debugging.</p></pre>1Gijs: <pre><p>liteide uses dbg ? Which is not very well supported on OSX (or by Go) ? I use liteide on OSX but stopped using the debugging 'feature' a long time ago because it failed almost always.</p>
<p>Fmt.* and log.* are my tools now...</p></pre>KimIlYong: <pre><p>I use LiteIDE and it works for me. Alhough the debugger is not perfect i can do what is neccessary: Breakpoints, Stepping and variable inspection.</p>
<p>Issues i have with LiteIDE are minor problems: Sometimes a var does not show up in the variable inspector window and i would like to see the value if i hover over the var in the src.</p></pre>MyPetHamster: <pre><p>Local variables don't show if they are held in registers. See <a href="https://github.com/golang/go/issues/2430" rel="nofollow">https://github.com/golang/go/issues/2430</a></p>
<p>However, LiteIDE uses gdb, so sometimes it will work, sometimes it won't.</p></pre>softiniodotcom: <pre><p>I am a big fan of Intellij IDEA so I look forward to when this is available. </p>
<p>Last time I tried the current available plugin, it did not work well. Will look at again once Jetbrain makes this available. Great News !</p></pre>arechsteiner: <pre><p>If you look at the contributors page of the plugin, you'll find that the top two contributors are Jetbrains employees:</p>
<p><a href="https://github.com/go-lang-plugin-org/go-lang-idea-plugin/graphs/contributors" rel="nofollow">https://github.com/go-lang-plugin-org/go-lang-idea-plugin/graphs/contributors</a></p>
<p>It started out as a third party plugin but now Jetbrains has dedicated staff to the project.</p></pre>dashausSP: <pre><p>Actually, the plugin is most stable and completely functional. For me it works really fine.</p></pre>schumacherfm: <pre><p>I self-compile the plugin to use always the tip and everything works fine :-)</p>
<p>here are the commits <a href="https://github.com/go-lang-plugin-org/go-lang-idea-plugin/commits/debugger" rel="nofollow">https://github.com/go-lang-plugin-org/go-lang-idea-plugin/commits/debugger</a> for the Delve debugger support. It may take a while until they merge it into master.</p></pre>jasonrichardsmith: <pre><p>I use Spew a lot
<a href="https://github.com/davecgh/go-spew" rel="nofollow">https://github.com/davecgh/go-spew</a></p>
<p>It is really handy, and super easy to throw into your code.</p></pre>lhxtx: <pre><p>Go spew and your logging package of choice. Even the built in log package can easily be set for 'levels' with a little boilerplate code. </p></pre>jbuberel: <pre><p>If you're trying to debug web-based applications, I've found something like this to be very useful at times:</p>
<ul>
<li>Make sure you escape the output!</li>
<li><p>Only use this in a development environment or mode. Do not do this in production!</p>
<pre><code>package main
import (
"fmt"
"html"
"net/http"
"github.com/davecgh/go-spew/spew"
)
func handler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/html")
fmt.Fprintf(w, "Hi there, %s!", r.URL.Path[1:])
fmt.Fprintf(w, "<!--\n" + html.EscapeString(spew.Sdump(w)) + "\n-->")
}
func main() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8080", nil)
}
</code></pre></li>
</ul>
<p>[update: added the html.EscapeString() and added warning to not use in production.] </p></pre>cyrusol: <pre><p>Is that Go's version of PHP's <code>var_dump()</code>?</p>
<p>A few days ago I got an email from a coworker: "Our debugging procedure is broken." - because we're using <code>var_dump()</code> most of the time.</p>
<p>Don't let bad habits become part of working with Go please.</p></pre>jbuberel: <pre><p>This is by no means a bad habit - using stack dumps and variable dumps is a reasonable method for troubleshooting problems in a development environment (a.k.a. "fixing bugs").</p>
<p>Instead of printing the values to the HTML response, you could also just log them:</p>
<pre><code>log.Printf("Spew: %v\n", spew.Sdump(w))
</code></pre>
<p>As others have pointed out, Go does not currently have a first-class source level debugger that is easy to use when debugging multi-threaded applications (like all web applications). </p>
<p>You just need to use these techniques appropriately.</p></pre>AnimalMachine: <pre><p>I'm surprised no one replied saying gdb works. Because I've used it to debug things. Granted, what I wanted was simple, but I was able to set break points and inspect the variables I wanted.</p>
<p><a href="https://golang.org/doc/gdb" rel="nofollow">https://golang.org/doc/gdb</a></p>
<p>I do support <a href="/u/robertmeta" rel="nofollow">/u/robertmeta</a>'s idea of logging though, which is why I made my own logging library.</p></pre>robertmeta: <pre><p>GDB barely sometimes works by accident... I wouldn't consider it dependable or useful. hehe</p>
<p>I tend to use structured loggers for easy parsing later -- <a href="https://github.com/Sirupsen/logrus">https://github.com/Sirupsen/logrus</a> in json output mode is great, the json is trivial to load later and do stuff with and slackrus can poke you on slack when really bad stuff happens.</p></pre>: <pre><p>[deleted]</p></pre>robertmeta: <pre><p>Actually -- doesn't matter gccgo or reference compiler, either way GDB still doesn't "understand" the internal runtime. </p></pre>
