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.

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

runtime: segfault in timeSleepUntil #35462

Open
bcmills opened this issue Nov 8, 2019 · 5 comments
Assignees
Milestone

Comments

@bcmills bcmills added this to the Go1.14 milestone Nov 8, 2019
@ianlancetaylor ianlancetaylor self-assigned this Nov 8, 2019
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 8, 2019

Any failure before https://golang.org/cl/205558, committed on Wed Nov 6 15:46:26 2019 +0000, is likely fixed by that commit. I think that leaves us with only one failure:

https://build.golang.org/log/9298618f82f5cb0e6d17e745644af793111adc4c

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 8, 2019

The stack trace implies that there is a nil entry in pp.timers. Which should, of course, be impossible.

I'm not having any luck reproducing this.

@ianlancetaylor

This comment has been minimized.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 13, 2019

Change https://golang.org/cl/206938 mentions this issue: runtime: acquire timersLocks around moveTimers

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 13, 2019

One way this could happen would be if the number of P's changes, and that causes some calls to moveTimers. That runs with the world stopped, but the sysmon thread can still kick in and look through the timers. If that happens concurrently with moveTimers, we could see garbage. I sent CL 206938 to fix that. But I'm not sure that explains all the failures here, as some of them don't have any obvious calls to runtime.GOMAXPROCS.

gopherbot pushed a commit that referenced this issue Nov 13, 2019
In the discussion of CL 171828 we decided that it was not necessary to
acquire timersLock around the call to moveTimers, because the world is
stopped. However, that is not correct, as sysmon runs even when the world
is stopped, and it calls timeSleepUntil which looks through the timers.
timeSleepUntil acquires timersLock, but that doesn't help if moveTimers
is running at the same time.

Updates #6239
Updates #27707
Updates #35462

Change-Id: I346c5bde594c4aff9955ae430b37c2b6fc71567f
Reviewed-on: https://go-review.googlesource.com/c/go/+/206938
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.