runtime: gcWriteBarrier requires g.m.p != nil even if g.m.dying > 0 #26575
Labels
FrozenDueToAge
NeedsFix
The path to resolution is known, but the work has not been done.
release-blocker
Milestone
Uh oh!
There was an error while loading. Please reload this page.
A signal can occur on a thread with no p, that is, where
g != nil && g.m != nil && g.m.p == nil
. Thus, the signal hander must not have any write barriers. A signal can cause a panic, which the signal handler implements by callingstartpanic_m
. The code instartpanic_m
is permitted to have write barriers, because write barriers are permitted, even ifg.m.p == nil
, ifg.m.dying > 0
. This check is made inwbBufFlush
.However, write barriers are currently implemented by calling
gcWriteBarrier
. And that function, written in assembler, assumes thatg.m.p != nil
. So whenstartpanic_m
has a write barrier, which it does when setting_g_.writebuf = nil
, we can get a segmentation violation while handling a signal.I believe this can happen starting in the 1.10 release.
cc @aclements
The text was updated successfully, but these errors were encountered: