runtime: inlined function doesn't appear in stack trace

[stvnrhodes]

Let's say I have a struct like the one below.

type st struct {
    i *struct {
    j int
    }
}

Sometimes I forget to check if a field is nil. If I do a return statement that ends up dereferencing a nil pointer, like http://play.golang.org/p/WzyNpsiBam, I would expect the stack trace from the panic to be on the same line as the return statement. Instead, the stack trace indicates that the nil pointer dereference happened on the same line as the caller.

Interestingly, the same thing happens if I assign to a variable first.
http://play.golang.org/p/M3q3cSLgBk

If I enter another function before returning the variable, the stack trace is correct.
http://play.golang.org/p/eOZc34Uya7

[minux]

It's because the function is inlined into main.

If you call another function bar, then foo will no longer be inlineable in
Go 1.4 and earlier (Go 1.5 enables transitive inline), so the traceback
is correct.

If you disable the inlining with -gcflags -l, then you will see the traceback
is correct.

We need more sophisticated pcln table to support traceback inlind
function calls.

[GeertJohan]

I just ran into the same problem and spent quite some time finding out that my function was inlined and the dereference causing the panic was actually somewhere else in my code.
Some simple examples: http://play.golang.org/p/zMiaWyuUWd

[divoxx]

I just got bit by this once more. What needs to happen for this to be included in the next possible release?

[randall77]

We need to figure out how to do it, then implement it.
I think we're kind of stuck on the first part. It isn't easy.

[ALTree]

(Some discussion is in #11432)

[dvyukov]

Got out of range panic in test on:

            result := replace(test.where, test.start, test.end, test.what)

while it actually happened somewhere over there:

func replace(where []byte, start, end int, what []byte) []byte {
    if len(what) >= end - start {
        where = append(where, what[end - start:]...)
        copy(where[start + len(what):], where[end:])
        copy(where[start:], what)
    } else {
        copy(where[start+len(what):], where[end:])
        where = where[:end - start - len(what)]
        copy(where[start:], what)
    }
    return where
}

Now that #11432 is fixed and the "how" part is resolved, can this be reconsidered?

[rsc]

We may have do some work on the inliner in the winter. /cc @aclements

[gopherbot]

CL https://golang.org/cl/37233 mentions this issue.