Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

runtime: stack trace line number is wrong #25708

Closed
alexbrainman opened this issue Jun 3, 2018 · 4 comments
Closed

runtime: stack trace line number is wrong #25708

alexbrainman opened this issue Jun 3, 2018 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.12

Comments

@alexbrainman
Copy link
Member

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
Copy link
Contributor

cc @dr2chase for line numbers

@josharian josharian added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 3, 2018
@josharian josharian added this to the Go1.12 milestone Jun 3, 2018
@randall77
Copy link
Contributor

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
Copy link
Member Author

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

@alexbrainman alexbrainman mentioned this issue Jan 18, 2019
Open
@randall77
Copy link
Contributor

randall77 commented Jan 18, 2019 •
edited

Let's discuss on #29797.

@golang golang locked and limited conversation to collaborators Jan 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.12
Development

No branches or pull requests
4 participants
@josharian @randall77 @gopherbot @alexbrainman