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: sigpanic in scanframeworker #28353

Closed
tbg opened this issue Oct 24, 2018 · 3 comments
Closed

runtime: sigpanic in scanframeworker #28353

tbg opened this issue Oct 24, 2018 · 3 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@tbg
Copy link

tbg commented Oct 24, 2018

A crash with the following stack trace on go1.10.3 was reported anonymously from a CockroachDB server (8 CPUs):

*log.safeError: stopper.go:182: runtime.errorString: runtime error: invalid memory address or nil pointer dereference
  File "runtime/asm_amd64.s", line 573, in call32
  File "runtime/panic.go", line 502, in gopanic
  File "runtime/panic.go", line 63, in panicmem
  File "runtime/signal_unix.go", line 388, in sigpanic
  File "runtime/mgcmark.go", line 827, in scanframeworker

My best reading of this is that scanframeworker code tried to log and instead hit an NPE (not sure where though, frame shouldn't be nil as it's already dereferenced earlier in the code):

print("runtime: frame ", funcname(f), " untyped locals ", hex(frame.varp-size), "+", hex(size), "\n")

If this hadn't NPEd, the stack trace would've been something like #17499.

Unfortunately, due to the nature of the report, I can neither reproduce this nor do I have more information about the environment in which this happened.

@bcmills
Copy link
Contributor

bcmills commented Oct 24, 2018

CC @aclements @RLH

@bcmills bcmills changed the title runtime: NPE before throw("missing stackmap") in scanframeworker runtime: sigpanic in scanframeworker Oct 24, 2018
@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 24, 2018
@bcmills bcmills added this to the Go1.10.5 milestone Oct 24, 2018
@tbg
Copy link
Author

tbg commented Oct 24, 2018

I should add that this happened on linux-amd64.

@dmitshur dmitshur modified the milestones: Go1.10.5, Go1.10.6 Nov 1, 2018
@dmitshur dmitshur modified the milestones: Go1.10.6, Go1.10.7 Dec 13, 2018
@FiloSottile FiloSottile modified the milestones: Go1.10.7, Go1.12 Dec 14, 2018
@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@ALTree
Copy link
Member

ALTree commented Jul 22, 2020

This report is 2 years old, the upstream issue was closed as a flake, the crash did not happen again in any non-ancient, currently supported Go version, and there's not much information here that can be used to reproduce or investigate the original problem; so let's write this off as a flake and close this. A new issue can be re-opened if the flake re-occurs.

@ALTree ALTree closed this as completed Jul 22, 2020
@golang golang locked and limited conversation to collaborators Jul 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

8 participants