Skip to content

runtime: netbsd/amd64 corruption during signal handling #7684

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
Closed
mikioh opened this issue Apr 2, 2014 · 13 comments
Closed

runtime: netbsd/amd64 corruption during signal handling #7684

mikioh opened this issue Apr 2, 2014 · 13 comments
Labels
FrozenDueToAge OS-NetBSD Suggested Issues that may be good for new contributors looking for work to do.
Milestone
Unplanned

Comments

@mikioh
Copy link
Contributor

mikioh commented Apr 2, 2014 

What steps will reproduce the problem?
1. fetch & build tip on netbsd/amd64, 6.1.2
2.
3.

What is the expected output? What do you see instead?
ok      net/textproto   0.004s
ok      net/url 0.003s
ok      os      0.463s
ok      os/exec 0.419s
fatal error: entersyscall

goroutine 25 [running]:
runtime.throw(0x660415)
        /home/mikioh/go/src/pkg/runtime/panic.c:520 +0x69 fp=0x7f7ff7d3fef0
runtime.entersyscall(0x4b25c7)
        /home/mikioh/go/src/pkg/runtime/proc.c:1493 +0x313 fp=0x7f7ff7d3ff18
syscall.Syscall(0x25, 0x2bf3, 0x1e, 0x0, 0x0, ...)
        /home/mikioh/go/src/pkg/syscall/asm_netbsd_amd64.s:17 +0x5 fp=0x7f7ff7d3ff20
syscall.Kill(0x2bf3, 0x1e, 0x0, 0x0)
        /home/mikioh/go/src/pkg/syscall/zsyscall_netbsd_amd64.go:648 +0x67 fp=0x7f7ff7d3ff68
(snip)

Please use labels and text to provide additional information.
% hg id
c1903a893ed7 tip

% uname -a
NetBSD vm6.localdomain 6.1.2 NetBSD 6.1.2 (GENERIC) amd64
@ianlancetaylor
Copy link
Member

Comment 2:

Labels changed: added release-go1.3, os-netbsd.

@dvyukov
Copy link
Member

dvyukov commented Apr 2, 2014

Comment 3:

Please attach the crash report with GOTRACEBACK=2. And also uncomment printf at
src/pkg/runtime/proc.c:1492 just before the panic.

@mikioh
Copy link
Contributor Author

mikioh commented Apr 2, 2014

Comment 4:

Sure, for now I'm offline, will try tonight.

@mikioh
Copy link
Contributor Author

mikioh commented Apr 2, 2014

Comment 5:

here you go. just tried with d572df89bed8 (officially i'm grabbing a coffee now).

Attachments:

  1. crashlog-GOTRACEBACK-crash-with-proc-print.txt (6792 bytes)

@minux
Copy link
Member

minux commented Apr 2, 2014

Comment 6:

does it reproduce each time? do you have any special settings?
I tried all.bash once and go test os/signal several times, no crash.

@dvyukov
Copy link
Member

dvyukov commented Apr 2, 2014

Comment 7:

Previously it was "fatal error: entersyscall" and now it is "fatal error: runtime: wrong
goroutine in newstack".
Do you believe it's the same bug that manifest itself in different ways?

@mikioh
Copy link
Contributor Author

mikioh commented Apr 2, 2014

Comment 8:

gotta go, but a bit.
> does it reproduce each time?
sometimes. seems a combo of clean.bash && all.bash makes it happen easier.
> do you have any special settings?
hm, openbsd/amd64 vm, 2 cores assigned.

@dvyukov
Copy link
Member

dvyukov commented Apr 2, 2014

Comment 9:

Ah, sorry, I see, the second fatal error is caused by printf in entersyscall.

@mikioh
Copy link
Contributor Author

mikioh commented Apr 2, 2014

Comment 10:

the second one..., yup. please change the description appropriately.

@dvyukov
Copy link
Member

dvyukov commented Apr 2, 2014

Comment 11:

From the crash report I can only figure out that something is badly corrupted before
runtime.entersyscall.
Apparently we can't use printf in entersyscall. You need some custom printing machinery
(potentially runtime.prints/printpointer made NOSPLIT) to print useful info.

@rsc
Copy link
Contributor

rsc commented Apr 3, 2014

Comment 12:

In the GOTRACEBACK crash log you can see the problem goroutine printed as 'goroutine 0'
and then at the end as 'goroutine 25' (they're definitely the same goroutine since they
have the same fp= stack pointers). That suggests that the g value which is active has
g->goid == 0 and is not the one in the actual goroutine list. That is, the g value is
completely bogus. You really need to make this happen under a debugger to have any
chance. Everything is set up wrong. Printing is not going to work.
I expect this will be a NetBSD-specific bug, so it will not block the 1.3 release.

Labels changed: added release-go1.3maybe, removed release-go1.3.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented May 9, 2014

Comment 13:

Labels changed: added release-none, suggested, removed release-go1.3maybe.

@mikioh mikioh added accepted Suggested Issues that may be good for new contributors looking for work to do. labels May 9, 2014
@rsc rsc removed the os-netbsd label Apr 10, 2015
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@mikioh
Copy link
Contributor Author

mikioh commented Jan 22, 2016

I think that the series of changesets for Go 1.6 fixes this issue somehow. Closing.

@mikioh mikioh closed this as completed Jan 22, 2016
@golang golang locked and limited conversation to collaborators Jan 23, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge OS-NetBSD Suggested Issues that may be good for new contributors looking for work to do.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@mikioh @rsc @minux @dvyukov @ianlancetaylor @gopherbot