runtime: stack trace line number is wrong

[alexbrainman]

What version of Go are you using (go version)?

go version devel +06b3260 Sat Jun 2 18:00:44 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

I do not know.

What operating system and processor architecture are you using (go env)?

I use Linux, but I cross-compiled example for Windows.

What did you do?

While debugging #25671 I compiled this program

ktye/goissues@72c9933#diff-3ccd738cae05756fce2ac5ba10cc4800

I then modified d20ef58a6d38 commit of golang.org/x/exp like this:

diff --git a/shiny/driver/internal/win32/win32.go b/shiny/driver/internal/win32/win32.go
index 3fc939b..d611853 100644
--- a/shiny/driver/internal/win32/win32.go
+++ b/shiny/driver/internal/win32/win32.go
@@ -12,6 +12,7 @@ package win32 // import "golang.org/x/exp/shiny/driver/internal/win32"
 import (
 	"fmt"
 	"runtime"
+	"runtime/debug"
 	"sync"
 	"syscall"
 	"unsafe"
@@ -118,7 +119,9 @@ func Show(hwnd syscall.Handle) {
 func Release(hwnd syscall.Handle) {
 	// TODO(andlabs): check for errors from this?
 	// TODO(andlabs): remove unsafe
-	_DestroyWindow(hwnd)
+	err := _DestroyWindow(hwnd)
+	fmt.Printf("ALEX: %v\n", err)
+	debug.PrintStack()
 	// TODO(andlabs): what happens if we're still painting?
 }

Then I run the program and that brought main window up, and I clicked "close" button of the window. And I see this stack trace:

C:\Users\Alex>u:\test
2018/06/03 12:09:23 received lifecycle.Event{From:StageFocused, To:StageDead, DrawContext:<nil>}: window 0xc000092000 should be closing now
ALEX: Access is denied.
goroutine 18 [running]:
runtime/debug.Stack(0x9, 0xc00008dd30, 0x1)
        /home/a/go/src/runtime/debug/stack.go:24 +0xae
runtime/debug.PrintStack()
        /home/a/go/src/runtime/debug/stack.go:16 +0x29
golang.org/x/exp/shiny/driver/internal/win32.Release(0x100306)
        /home/a/src/golang.org/x/exp/shiny/driver/internal/win32/win32.go:124 +0x95
golang.org/x/exp/shiny/driver/windriver.(*windowImpl).Release(0xc000092000)
        /home/a/src/golang.org/x/exp/shiny/driver/windriver/window.go:42 +0x35
main.createWindow(0x510180, 0x5b9680, 0x0)
        /home/a/src/github.com/ktye/goissues/25671/main.go:63 +0x4d6
main.main.func1(0x510180, 0x5b9680)
        /home/a/src/github.com/ktye/goissues/25671/main.go:31 +0x41
golang.org/x/exp/shiny/driver/windriver.Main.func1()
        /home/a/src/golang.org/x/exp/shiny/driver/windriver/windriver.go:22 +0x44
golang.org/x/exp/shiny/driver/internal/win32.screenWindowWndProc.func1()
        /home/a/src/golang.org/x/exp/shiny/driver/internal/win32/win32.go:304 +0x30
created by golang.org/x/exp/shiny/driver/internal/win32.screenWindowWndProc
        /home/a/src/golang.org/x/exp/shiny/driver/internal/win32/win32.go:303 +0x123

C:\Users\Alex>

What did you expect to see?

I expect stack trace point to the line 48 with defer w.Release()

        /home/a/src/github.com/ktye/goissues/25671/main.go:48 ....

What did you see instead?

Stack trace points me to the line 63 with return

        /home/a/src/github.com/ktye/goissues/25671/main.go:63 +0x4d6

Thank you.

Alex

[josharian]

cc @dr2chase for line numbers

[randall77]

This is intentional. We chose to have defers appear to be called at the return from the function, not the place where they were deferred.
Dup of #21877.

[alexbrainman]

This is intentional. We chose to have defers appear to be called at the return from the function, not the place where they were deferred.

Thanks for replying.

But, if you point me to the return line, how would I know that the problem is in my defer that could be miles away? What happens if I have 2 defers in the function? Which of the 2 has the problem?

Alex

[randall77]

Let's discuss on #29797.