aboutsummaryrefslogtreecommitdiff
path: root/src/net/http/httputil
diff options
context:
space:
mode:
authorIan Lance Taylor <iant@golang.org>2021-07-28 21:09:31 -0700
committerIan Lance Taylor <iant@golang.org>2021-07-29 15:30:38 +0000
commit70fd4e47d73b92fe90e44ac785e2f98f9df0ab67 (patch)
treeb3e27a617fa1b6d191dac8a40c99142b96f1eb50 /src/net/http/httputil
parent9eee0ed4391942c73157c868a9ddcfdef48982f9 (diff)
downloadgo-70fd4e47d73b92fe90e44ac785e2f98f9df0ab67.tar.xz
runtime: avoid possible preemption when returning from Go to C
When returning from Go to C, it was possible for the goroutine to be preempted after calling unlockOSThread. This could happen when there a context function installed by SetCgoTraceback set a non-zero context, leading to a defer call in cgocallbackg1. The defer function wrapper, introduced in 1.17 as part of the regabi support, was not nosplit, and hence was a potential preemption point. If it did get preempted, the G would move to a new M. It would then attempt to return to C code on a different stack, typically leading to a SIGSEGV. Fix this in a simple way by postponing the unlockOSThread until after the other defer. Also check for the failure condition and fail early, rather than waiting for a SIGSEGV. Without the fix to cgocall.go, the test case fails about 50% of the time on my laptop. Fixes #47441 Change-Id: Ib8ca13215bd36cddc2a49e86698824a29c6a68ba Reviewed-on: https://go-review.googlesource.com/c/go/+/338197 Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Diffstat (limited to 'src/net/http/httputil')
0 files changed, 0 insertions, 0 deletions