Issue 108780044: code review 108780044: [release-branch.go1.3] runtime: fix panic stack during ...

Keyboard Shortcuts

	File
u :	up to issue
m :	publish + mail comments
M :	edit review message
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line
<Enter> :	respond to / edit current comment
d :	mark current comment as done

	Issue
u :	up to list of issues
m :	publish + mail comments
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue
# :	close issue

	Comment/message editing
<Ctrl> + s or <Ctrl> + Enter :	save comment
<Esc> :	cancel edit

Issue 108780044: code review 108780044: [release-branch.go1.3] runtime: fix panic stack during ... (Closed)

Can't Edit
Can't Publish+Mail
Start Review

Created:
10 years, 11 months ago by rsc

Modified:
10 years, 11 months ago

Reviewers:
iant

CC:
golang-codereviews, iant, r

Visibility:
Public.

Description

[release-branch.go1.3] runtime: fix panic stack during runtime.Goexit during panic ««« CL 102220043 / 00224712f89e runtime: fix panic stack during runtime.Goexit during panic A runtime.Goexit during a panic-invoked deferred call left the panic stack intact even though all the stack frames are gone when the goroutine is torn down. The next goroutine to reuse that struct will have a bogus panic stack and can cause the traceback routines to walk into garbage. Most likely to happen during tests, because t.Fatal might be called during a deferred func and uses runtime.Goexit. This "not enough cleared in Goexit" failure mode has happened to us multiple times now. Clear all the pointers that don't make sense to keep, not just gp->panic. Fixes issue 8158. LGTM=iant, dvyukov R=iant, dvyukov CC=golang-codereviews https://codereview.appspot.com/102220043 »»»

		Unified diffs	Side-by-side diffs	Delta from patch set	Stats (+47 lines, -0 lines)			Patch
	M	src/pkg/runtime/proc.c	View	1	1 chunk	+6 lines, -0 lines	0 comments	Download
	A	test/fixedbugs/issue8158.go	View	1	1 chunk	+41 lines, -0 lines	0 comments	Download

Messages

Total messages: 3

Expand All Messages | Collapse All Messages

rsc

Hello golang-codereviews@googlegroups.com (cc: iant, r), I'd like you to review this change to https://code.google.com/p/go/

10 years, 11 months ago (2014-06-06 20:53:47 UTC) #1

rsc

10 years, 11 months ago (2014-06-07 02:07:29 UTC) #3

*** Submitted as https://code.google.com/p/go/source/detail?r=96c74cf6dc10 ***

[release-branch.go1.3] runtime: fix panic stack during runtime.Goexit during
panic

««« CL 102220043 / 00224712f89e
runtime: fix panic stack during runtime.Goexit during panic

A runtime.Goexit during a panic-invoked deferred call
left the panic stack intact even though all the stack frames
are gone when the goroutine is torn down.
The next goroutine to reuse that struct will have a
bogus panic stack and can cause the traceback routines
to walk into garbage.

Most likely to happen during tests, because t.Fatal might
be called during a deferred func and uses runtime.Goexit.

This "not enough cleared in Goexit" failure mode has
happened to us multiple times now. Clear all the pointers
that don't make sense to keep, not just gp->panic.

Fixes issue 8158.

LGTM=iant, dvyukov
R=iant, dvyukov
CC=golang-codereviews
https://codereview.appspot.com/102220043
»»»

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://codereview.appspot.com/108780044

Expand All Messages | Collapse All Messages