We have some code for decoding (or trying to make the most sense out of
those values) in our web framework - aiming for a release at the end of
this month.

What you're getting is basically a stack dump of the top 5 Go values. This
might also include return values. The meaning of the value and the number
of fields it's represented by depends on the data type, which you can get
from debug/gosym. Use the GoType field in Sym, casting it to a reflect.Type
(this requires using unsafe) and you'll get the value type.

Each field on the dump after the function name represents a word. Depending
on the type, you're looking a 1-word types, 2-word types or 3-word types.
Note that this is derived from the fact the Go will pass structs up to 3
words by value, while bigger values will be passed by reference. This is an
implementation detail and might change at any time.

Some common cases (from memory, it might not be completely accurate):

     pointer, map, int and almost any basic type: 1 word
     strings: 2 words, first is pointer to data, second is length
     slice: 3 words, first is pointer to data, second is length, third is

Also note that gosym might not always return the parameter in the same
order that the function declaration takes them. However, their Value field
represents their offset in the stack, so you can sort them by Value in
increasing order to get them ordered in the same way they were declared.

On Sunday, March 9, 2014 6:26:15 PM UTC+1, Maher Saba wrote:


I am trying to make sense of the printed arguments of a function during
dumping the stack in a panic. I believe the code is
in src/pkg/runtime/traceback_x86.c: runtime·gentraceback.

I have a couple of questions:

1- I think the first thing that is printed is the receiver address. That's
nice but I think not too many people can decipher it into a useful data on
the fly. Are there any tips/tricks to help figure out what to do with such

2- The number of printed argument seems to be inconsistent. I can tell
it's limited to 5 but I have functions with one arguments and for some of
them I see 4 printed arguments, for some I see 2, and something, I see 5
with the ... printed at the end. Is there a good way to understand the

The bottom line is that every time I am trying to debug a panic, I end up
instrumenting the code and hope for a repro. I am wondering if I can avoid
that since I don't may not be able to repro the situation easily. I am
asking if printing the info from the stack can be beefed up to dump known
generic data structs such as the first few chars of a string, or the
current index of a slice with the len and cap in the case of an index out
of range panic,... etc. I have no issue if you print much more info during
a crash but without the need of creating a process dump and doing old
fashion crash dump debugging.

And yes, I aware that if I write bug free code, I don't have to deal with
panics :)

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.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 5 | next ›
Discussion Overview
groupgolang-nuts @
postedMar 10, '14 at 5:49a
activeMar 11, '14 at 6:20p



site design / logo © 2022 Grokbase