semantics of panic stack traces

[Dan Kortschak]

I'm trying to get my head around a panic stack trace from a user
report[1].

The parameter value make very little sense to me based on what they
should be from following the program logic. For example the {0x0?, 0x0,
0x1?} (a slice header len=0) in

github.com/elastic/beats/v7/winlogbeat/sys/wineventlog.evtFormatMessage(0xc0003f62d0?, 0x23?, 0x0?, {0x0?, 0x0, 0x1?}, 0x1?)
github.com/elastic/beats/v7/winlogbeat/sys/wineventlog/format_message.go:81 +0xa5 fp=0xc00034ae88 sp=0xc00034ad98 pc=0x176f645

means that (from program logic) the 4th (length) and 5th (pointer)
parameters in

github.com/elastic/beats/v7/winlogbeat/sys/wineventlog._EvtFormatMessage(0x23?, 0x3600700?, 0x0, 0x0, 0xc000d5e978?, 0x1, 0x0, 0x0?, 0x0?)
github.com/elastic/beats/v7/winlogbeat/sys/wineventlog/zsyscall_windows.go:132 +0xf2 fp=0xc00034ad98 sp=0xc00034acf0 pc=0x177f152

should be 0 and 0 AFAICS. But this is not the case; the 5th is
0xc000d5e978?.

What am I failing to understand here?

thanks
Dan

[1]https://discuss.elastic.co/t/winlogbeat-unable-to-start-due-to-error/343190

[Ian Lance Taylor]

First I have to say that that code is not safe. It violates the
unsafe.Pointer rules. The Windows function EvtFormatMessage takes a
pointer. The Go function evtFormatMessage converts the slice address
to uintptr, and passes that. The conversion to uintptr is permitted
in the call to EvtFormatMessage, but that is not where it takes place.
So this code is wrong, although in practice it will usually work as
expected.

That aside, I don't think you're misunderstanding anything. The ? in
the stack traceback means that the value might be wrong. That ? is
printed when the value is not live, meaning that the compiler may have
overwritten or discarded the value at the point of the stack
traceback. In this case the "values" slice is dead at the point of
the call to _EvtFormatMessage. Likely the values shown in the call to
evtFormatMessage are simply wrong.

Ian