aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/testdata
AgeCommit message (Collapse)Author
2021-11-11runtime: bypass scheduler when doing traceback for goroutine profileCherry Mui
When acquire a goroutine profile, we stop the world then acquire a stack trace for each goroutine. When cgo traceback is used, the traceback code may call the cgo traceback function using cgocall. As the world is stopped, cgocall will be blocked at exitsyscall, causing a deadlock. Bypass the scheduler (using asmcgocall) to fix this. Change-Id: Ic4e596adc3711310b6a983d73786d697ef15dd72 Reviewed-on: https://go-review.googlesource.com/c/go/+/362757 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-11-10runtime: rewrite TestPhysicalMemoryUtilizationMichael Anthony Knyszek
This test changes TestPhysicalMemoryUtilization to be simpler, more robust, and more honest about what's going on. Fixes #49411. Change-Id: I913ef055c6e166c104c62595c1597d44db62018c Reviewed-on: https://go-review.googlesource.com/c/go/+/362978 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com>
2021-10-27runtime/testdata/testprogcgo: fix TestCgoPanicCallbackCuong Manh Le
A cgo file with "//export" declarations is not permitted to have function definitions in the cgo comments. Fixes #49188 Change-Id: I5c24b62b259871473ee984cea96a0edd7d42d23a Reviewed-on: https://go-review.googlesource.com/c/go/+/359195 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-10-26runtime: fix cgo signals detectionMichael Pratt
CL 64070 removed lockOSThread from the cgocall path, but didn't update the signal-in-cgo detection in sighandler. As a result, signals that arrive during a cgo call are treated like they arrived during Go execution, breaking the traceback. Update the cgo detection to fix the backtrace. Fixes #47522 Change-Id: I61d77ba6465f55e3e6187246d79675ba8467ec23 Reviewed-on: https://go-review.googlesource.com/c/go/+/339989 Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2021-10-06all: use bytes.Cut, strings.CutRuss Cox
Many uses of Index/IndexByte/IndexRune/Split/SplitN can be written more clearly using the new Cut functions. Do that. Also rewrite to other functions if that's clearer. For #46336. Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448 Reviewed-on: https://go-review.googlesource.com/c/go/+/351711 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-08-28runtime: add test case for checkptr alignment with nested expressionCuong Manh Le
Discover while working on moving checkptr instrumentation from walk to SSA generation. Change-Id: I3f4a41fe4ad308b86c7c57d14b6ccc7c613e7f98 Reviewed-on: https://go-review.googlesource.com/c/go/+/345432 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-07-29runtime: avoid possible preemption when returning from Go to CIan Lance Taylor
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>
2021-07-28runtime: don't crash on nil pointers in checkptrAlignmentMatthew Dempsky
Ironically, checkptrAlignment had a latent case of bad pointer arithmetic: if ptr is nil, then `add(ptr, size-1)` might produce an illegal pointer value. The fix is to simply check for nil at the top of checkptrAlignment, and short-circuit if so. This CL also adds a more explicit bounds check in checkptrStraddles, rather than relying on `add(ptr, size-1)` to wrap around. I don't think this is necessary today, but it seems prudent to be careful. Fixes #47430. Change-Id: I5c50b2f7f41415dbebbd803e1b8e7766ca95e1fd Reviewed-on: https://go-review.googlesource.com/c/go/+/338029 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2021-06-28cmd/compile,runtime: change unsafe.Slice((*T)(nil), 0) to return []T(nil)Matthew Dempsky
This CL removes the unconditional OCHECKNIL check added in walkUnsafeSlice by instead passing it as a pointer to runtime.unsafeslice, and hiding the check behind a `len == 0` check. While here, this CL also implements checkptr functionality for unsafe.Slice and disallows use of unsafe.Slice with //go:notinheap types. Updates #46742. Change-Id: I743a445ac124304a4d7322a7fe089c4a21b9a655 Reviewed-on: https://go-review.googlesource.com/c/go/+/331070 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2021-06-12runtime: testprogcgo: don't call exported Go functions directly from GoIan Lance Taylor
Instead route through a C function, to avoid declaration conflicts between the declaration needed in the cgo comment and the declaration generated by cgo in _cgo_export.h. This is not something user code will ever do, so no need to make it work in cgo. Fixes #46502 Change-Id: I1bfffdc76ef8ea63e3829871298d0774157957a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/327309 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
2021-05-21runtime: wait for Go runtime to initialize in Windows signal testJason A. Donenfeld
The test harness waits for "ready" as a sign that the Go runtime has installed its signal handler and is ready to be tested. But actually, while LoadLibrary starts the loading of the Go runtime, it does so asynchronously, so the "ready" sign is potentially premature and certainly racy. However, all exported cgo entry points make a call to _cgo_wait_runtime_init_done which waits for that asynchronous initialization to complete. Therefore, this commit fixes the test to call into the exported "Dummy" cgo function before emitting the "ready" sign, so that we're sure the Go runtime is actually loaded. Updates #45638. Change-Id: I9b12b172d45bdcc09d54dd301de3a3e499544834 Reviewed-on: https://go-review.googlesource.com/c/go/+/321769 Trust: Jason A. Donenfeld <Jason@zx2c4.com> Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-27runtime: add missing import "C" in TestLibraryCtrlHandlerAlex Brainman
CL 211139 added TestLibraryCtrlHandler. But the CL left out import "C" line in the test file that is supposed to be build with Cgo. While debugging issue #45638, I discovered that the DLL built during TestLibraryCtrlHandler does not have Dummy function. Adding import "C" makes Dummy function appear in DLL function list. TestLibraryCtrlHandler does not actually calls Dummy function. So I don't see how this change affects issue #45638, but still let's make this code correct. Updates #45638 Change-Id: Ibab8fed29ef2ae446d0815842cf0bd040a5fb943 Reviewed-on: https://go-review.googlesource.com/c/go/+/313350 Trust: Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-23runtime/testdata: fix testprogcgo for windows/arm64Russ Cox
Our toolchain does not like -mnop-fun-dllimport. Change-Id: Iaaee01fe0f4b0959406a35eb13aefa390116b483 Reviewed-on: https://go-review.googlesource.com/c/go/+/312043 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-04-22runtime: don't run TestCrashDumpsAllThreads in parallelIan Lance Taylor
It sometimes seems to time out on slow systems, perhaps due to being run at the same time as a lot of other work. Also move the code to testdata/testprog, so that we don't have to build it separately. I hope that this Fixes #35356 Change-Id: I875b858fa23836513ae14d3116461e22fffd5352 Reviewed-on: https://go-review.googlesource.com/c/go/+/312510 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-03-15all: run gofmtPrajwal Koirala
Fixes #44980 Change-Id: Icef35319d1582d8367c8911e15d11b0224957327 GitHub-Last-Rev: 2113e97e837c1ef5de9ba6a7bd62db92e644c500 GitHub-Pull-Request: golang/go#45005 Reviewed-on: https://go-review.googlesource.com/c/go/+/301632 Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Josh Bleecher Snyder <josharian@gmail.com>
2021-01-27runtime: make sure to remove open-coded defer entries in all cases after a ↵Dan Scales
recover We add entries to the defer list at panic/goexit time on-the-fly for frames with open-coded defers. We do this so that we can correctly process open-coded defers and non-open-coded defers in the correct order during panics/goexits. But we need to remove entries for open-coded defers from the defer list when there is a recover, since those entries may never get removed otherwise and will get stale, since their corresponding defers may now be processed normally (inline). This bug here is that we were only removing higher-up stale entries during a recover if all defers in the current frame were done. But we could have more defers in the current frame (as the new test case shows). In this case, we need to leave the current defer entry around for use by deferreturn, but still remove any stale entries further along the chain. For bug 43921, simple change that we should abort the removal loop for any defer entry that is started (i.e. in process by a still not-recovered outer panic), even if it is not an open-coded defer. This change does not fix bug 43920, which looks to be a more complex fix. Fixes #43882 Fixes #43921 Change-Id: Ie05b2fa26973aa26b25c8899a2abc916090ee4f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/286712 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-01-27runtime: block console ctrlhandler when the signal is handledNuno Cruces
Fixes #41884 I can confirm this change fixes my issue. I can't confirm that this doesn't break any and everything else. I see that this code has been tweaked repeatedly, so I would really welcome guidance into further testing. Change-Id: I1986dd0c2f30cfe10257f0d8c658988d6986f7a6 GitHub-Last-Rev: 92f02c96973e12f1472511bcf3c5ebb36c6b0440 GitHub-Pull-Request: golang/go#41886 Reviewed-on: https://go-review.googlesource.com/c/go/+/261057 Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Trust: Jason A. Donenfeld <Jason@zx2c4.com> Trust: Alex Brainman <alex.brainman@gmail.com>
2020-12-09all: update to use os.ReadFile, os.WriteFile, os.CreateTemp, os.MkdirTempRuss Cox
As part of #42026, these helpers from io/ioutil were moved to os. (ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.) Update the Go tree to use the preferred names. As usual, code compiled with the Go 1.4 bootstrap toolchain and code vendored from other sources is excluded. ReadDir changes are in a separate CL, because they are not a simple search and replace. For #42026. Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3 Reviewed-on: https://go-review.googlesource.com/c/go/+/266365 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-11-24runtime: use inlined function name for traceback elisionAustin Clements
Currently, gentraceback decides which frames to print or elide when unwinding inlined frames using only the name of the outermost function. If the outermost function should be elided, then inlined functions will also be elided, even if they shouldn't be. This happens in practice in at least one situation. As of CL 258938, exported Go functions (and functions they call) can now be inlined into the generated _cgoexp_HASH_FN function. The runtime elides _cgoexp_HASH_FN from tracebacks because it doesn't contain a ".". Because of this bug, it also elides anything that was inlined into it. This CL fixes this by synthesizing a funcInfo for the inlined functions to pass to showframe. Fixes #42754. Change-Id: Ie6c663a4a1ac7f0d4beb1aa60bc26fc8cddd0f9d Reviewed-on: https://go-review.googlesource.com/c/go/+/272131 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-11-24runtime/testdata/testprogcgo: refactor CrashTracebackAustin Clements
This moves the C part of the CrashTraceback test into its own file in preparation for adding a test that transitions back into Go. Change-Id: I9560dcfd80bf8a1d30809fd360f958f5261ebb01 Reviewed-on: https://go-review.googlesource.com/c/go/+/272130 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-11-09Revert "runtime: make stack traces of endless recursion print only top and ↵Emmanuel Odeke
bottom 50" This reverts commit 3a81338622eb5c8b94f11001855e2a68a9e36bed. Reason for revert: Some edge cases not properly covered due to changes within runtime traceback generation since 2017, that need to be examined. This change landed very late in the Go1.16 cycle. Change-Id: I8cf6f46ea0ef6161d878e79943e6c7cdac94bccf Reviewed-on: https://go-review.googlesource.com/c/go/+/268577 Trust: Emmanuel Odeke <emmanuel@orijtech.com> Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-11-06runtime: make stack traces of endless recursion print only top and bottom 50Emmanuel T Odeke
This CL makes it so that instead of printing massive stack traces during endless recursion, which spams users and aren't useful, it now prints out the top and bottom 50 frames. If the number of frames <= 100 (_TracebackMaxFrames), we'll just print all the frames out. Modified gentraceback to return counts of: * ntotalframes * nregularframes which allows us to get accurate counts of the various kinds of frames. While here, also fixed a bug that resulted from CL 37222, in which we no longer accounted for decrementing requested frame skips, and assumed that when printing, that skip would always be 0. The fix is instead to add precondition that we'll only print if skip <= 0, but also decrement skip as we iterate. Fixes #7181. Fixes #24628. Change-Id: Ie31ec6413fdfbe43827b254fef7d99ea26a5277f Reviewed-on: https://go-review.googlesource.com/c/go/+/37222 Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Emmanuel Odeke <emmanuel@orijtech.com>
2020-10-28runtime: block signals in needm before allocating MIan Lance Taylor
Otherwise, if a signal occurs just after we allocated the M, we can deadlock if the signal handler needs to allocate an M itself. Fixes #42207 Change-Id: I76f44547f419e8b1c14cbf49bf602c6e645d8c14 Reviewed-on: https://go-review.googlesource.com/c/go/+/265759 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-10-20all: update references to symbols moved from io/ioutil to ioRuss Cox
The old ioutil references are still valid, but update our code to reflect best practices and get used to the new locations. Code compiled with the bootstrap toolchain (cmd/asm, cmd/dist, cmd/compile, debug/elf) must remain Go 1.4-compatible and is excluded. Also excluded vendored code. For #41190. Change-Id: I6d86f2bf7bc37a9d904b6cee3fe0c7af6d94d5b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/263142 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2020-10-20all: update references to symbols moved from os to io/fsRuss Cox
The old os references are still valid, but update our code to reflect best practices and get used to the new locations. Code compiled with the bootstrap toolchain (cmd/asm, cmd/dist, cmd/compile, debug/elf) must remain Go 1.4-compatible and is excluded. For #41190. Change-Id: I8f9526977867c10a221e2f392f78d7dec073f1bd Reviewed-on: https://go-review.googlesource.com/c/go/+/243907 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2020-08-20cmd/compile: fix checkptr handling of &^Matthew Dempsky
checkptr has code to recognize &^ expressions, but it didn't take into account that "p &^ x" gets rewritten to "p & ^x" during walk, which resulted in false positive diagnostics. This CL changes walkexpr to mark OANDNOT expressions with Implicit when they're rewritten to OAND, so that walkCheckPtrArithmetic can still recognize them later. It would be slightly more idiomatic to instead mark the OBITNOT expression as Implicit (as it's a compiler-generated Node), but the OBITNOT expression might get constant folded. It's not worth the extra complexity/subtlety of relying on n.Right.Orig, so we set Implicit on the OAND node instead. To atone for this transgression, I add documentation for nodeImplicit. Fixes #40917. Change-Id: I386304171ad299c530e151e5924f179e9a5fd5b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/249477 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2020-05-29runtime: no SIGWINCH to pgrp while GDB is runningMichael Pratt
When run with stdin == /dev/null and stdout/stderr == pipe (i.e., as os/exec.Command.CombinedOutput), GDB suffers from a bug (https://sourceware.org/bugzilla/show_bug.cgi?id=26056) that causes SIGSEGV when sent a SIGWINCH signal. Package runtime tests TestEINTR and TestSignalDuringExec both send SIGWINCH signals to the entire process group, thus including GDB if one of the GDB tests is running in parallel. TestEINTR only intends its signals for the current process, so it is changed to do so. TestSignalDuringExec, really does want its signals to go to children. However, it does not call t.Parallel(), so it won't run at the same time as GDB tests. This is a simple fix, but GDB is vulnerable, so we must be careful not to add new parallel tests that send SIGWINCH to the entire process group. Fixes #39021 Change-Id: I803606fb000f08c65c1b10ec554d4ef6819e5dd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/235557 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-05-26runtime, time: gofmtTobias Klauser
Change-Id: Ib36a5f239db5af497aae122eba049c15d0d4c4a8 Reviewed-on: https://go-review.googlesource.com/c/go/+/235139 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-05-21runtime: detect and report zombie slots during sweepingAustin Clements
A zombie slot is a slot that is marked, but isn't allocated. This can indicate a bug in the GC, or a bad use of unsafe.Pointer. Currently, the sweeper has best-effort detection for zombie slots: if there are more marked slots than allocated slots, then there must have been a zombie slot. However, this is imprecise since it only compares totals and it reports almost no information that may be helpful to debug the issue. Add a precise check that compares the mark and allocation bitmaps and reports detailed information if it detects a zombie slot. No appreciable effect on performance as measured by the sweet benchmarks: name old time/op new time/op delta BiogoIgor 15.8s ± 2% 15.8s ± 2% ~ (p=0.421 n=24+25) BiogoKrishna 15.6s ± 2% 15.8s ± 5% ~ (p=0.082 n=22+23) BleveIndexBatch100 4.90s ± 3% 4.88s ± 2% ~ (p=0.627 n=25+24) CompileTemplate 204ms ± 1% 205ms ± 0% +0.22% (p=0.010 n=24+23) CompileUnicode 77.8ms ± 2% 78.0ms ± 1% ~ (p=0.236 n=25+24) CompileGoTypes 729ms ± 0% 731ms ± 0% +0.26% (p=0.000 n=24+24) CompileCompiler 3.52s ± 0% 3.52s ± 1% ~ (p=0.152 n=25+25) CompileSSA 8.06s ± 1% 8.05s ± 0% ~ (p=0.192 n=25+24) CompileFlate 132ms ± 1% 132ms ± 1% ~ (p=0.373 n=24+24) CompileGoParser 163ms ± 1% 164ms ± 1% +0.32% (p=0.003 n=24+25) CompileReflect 453ms ± 1% 455ms ± 1% +0.39% (p=0.000 n=22+22) CompileTar 181ms ± 1% 181ms ± 1% +0.20% (p=0.029 n=24+21) CompileXML 244ms ± 1% 244ms ± 1% ~ (p=0.065 n=24+24) CompileStdCmd 15.8s ± 2% 15.7s ± 2% ~ (p=0.059 n=23+24) FoglemanFauxGLRenderRotateBoat 13.4s ±11% 12.8s ± 0% ~ (p=0.377 n=25+24) FoglemanPathTraceRenderGopherIter1 18.6s ± 0% 18.6s ± 0% ~ (p=0.696 n=23+24) GopherLuaKNucleotide 28.7s ± 4% 28.6s ± 5% ~ (p=0.700 n=25+25) MarkdownRenderXHTML 250ms ± 1% 248ms ± 1% -1.01% (p=0.000 n=24+24) [Geo mean] 1.60s 1.60s -0.11% (https://perf.golang.org/search?q=upload:20200517.6) For #38702. Change-Id: I8af1fefd5fbf7b9cb665b98f9c4b73d1d08eea81 Reviewed-on: https://go-review.googlesource.com/c/go/+/234100 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-05-21runtime: disable preemption in startTemplateThreadMichael Pratt
When a locked M wants to start a new M, it hands off to the template thread to actually call clone and start the thread. The template thread is lazily created the first time a thread is locked (or if cgo is in use). stoplockedm will release the P (_Pidle), then call handoffp to give the P to another M. In the case of a pending STW, one of two things can happen: 1. handoffp starts an M, which does acquirep followed by schedule, which will finally enter _Pgcstop. 2. handoffp immediately enters _Pgcstop. This only occurs if the P has no local work, GC work, and no spinning M is required. If handoffp starts an M, and must create a new M to do so, then newm will simply queue the M on newmHandoff for the template thread to do the clone. When a stop-the-world is required, stopTheWorldWithSema will start the stop and then wait for all Ps to enter _Pgcstop. If the template thread is not fully created because startTemplateThread gets stopped, then another stoplockedm may queue an M that will never get created, and the handoff P will never leave _Pidle. Thus stopTheWorldWithSema will wait forever. A sequence to trigger this hang when STW occurs can be visualized with two threads: T1 T2 ------------------------------- ----------------------------- LockOSThread LockOSThread haveTemplateThread == 0 startTemplateThread haveTemplateThread = 1 newm haveTemplateThread == 1 preempt -> schedule g.m.lockedExt++ gcstopm -> _Pgcstop g.m.lockedg = ... park g.lockedm = ... return ... (any code) preempt -> schedule stoplockedm releasep -> _Pidle handoffp startm (first 3 handoffp cases) newm g.m.lockedExt != 0 Add to newmHandoff, return park Note that the P in T2 is stuck sitting in _Pidle. Since the template thread isn't running, the new M will not be started complete the transition to _Pgcstop. To resolve this, we disable preemption around the assignment of haveTemplateThread and the creation of the template thread in order to guarantee that if handTemplateThread is set then the template thread will eventually exist, in the presence of stops. Fixes #38931 Change-Id: I50535fbbe2f328f47b18e24d9030136719274191 Reviewed-on: https://go-review.googlesource.com/c/go/+/232978 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-05-20runtime: allocate fewer bytes during TestEINTRBryan C. Mills
This will hopefully address the occasional "runtime: out of memory" failures observed on the openbsd-arm-jsing builder: https://build.golang.org/log/c296d866e5d99ba401b18c1a2ff3e4d480e5238c Also make the "spin" and "winch" loops concurrent instead of sequential to cut down the test's running time. Finally, change Block to coordinate by closing stdin instead of sending SIGINT. The SIGINT handler wasn't necessarily registered by the time the signal was sent. Updates #20400 Updates #39043 Change-Id: Ie12fc75b87e33847dc25a12edb4126db27492da6 Reviewed-on: https://go-review.googlesource.com/c/go/+/234538 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-05-13runtime: reduce timing sensitivity in TestEINTRBryan C. Mills
- Don't assume that a process interrupted at 100μs intervals will have enough remaining time to make progress. (Stop sending signals in between signal storms to allow the process to quiesce.) - Don't assume that a child process that spins for 1ms will block long enough for the parent process to receive signals or make meaningful progress. (Instead, have the child block indefinitely, and unblock it explicitly after the signal storm.) For #39043 Updates #22838 Updates #20400 Change-Id: I85cba23498c346a637e6cfe8684ca0c478562a93 Reviewed-on: https://go-review.googlesource.com/c/go/+/233877 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-05-11internal/poll, os: loop on EINTRIan Lance Taylor
Historically we've assumed that we can install all signal handlers with the SA_RESTART flag set, and let the system restart slow functions if a signal is received. Therefore, we don't have to worry about EINTR. This is only partially true, and we've added EINTR checks already for connect, and open/read on Darwin, and sendfile on Solaris. Other cases have turned up in #36644, #38033, and #38836. Also, #20400 points out that when Go code is included in a C program, the C program may install its own signal handlers without SA_RESTART. In that case, Go code will see EINTR no matter what it does. So, go ahead and check for EINTR. We don't check in the syscall package; people using syscalls directly may want to check for EINTR themselves. But we do check for EINTR in the higher level APIs in os and net, and retry the system call if we see it. This change looks safe, but of course we may be missing some cases where we need to check for EINTR. As such cases turn up, we can add tests to runtime/testdata/testprogcgo/eintr.go, and fix the code. If there are any such cases, their handling after this change will be no worse than it is today. For #22838 Fixes #20400 Fixes #36644 Fixes #38033 Fixes #38836 Change-Id: I7e46ca8cafed0429c7a2386cc9edc9d9d47a6896 Reviewed-on: https://go-review.googlesource.com/c/go/+/232862 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-05-08runtime: use first line of cpuset output on FreeBSDSteven Hartland
Fix TestFreeBSDNumCPU on newer versions of FreeBSD which have multi line output from cpuset e.g. cpuset -g -p 4141 pid 4141 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8 pid 4141 domain policy: first-touch mask: 0, 1 The test now uses just the first line of output. Fixes #38937 Fixes #25924 Change-Id: If082ee6b82120ebde4dc437e58343b3dad69c65f Reviewed-on: https://go-review.googlesource.com/c/go/+/232801 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-04-24runtime: sleep in TestSegv program to let signal be deliveredIan Lance Taylor
Since we're sleeping rather than waiting for the goroutines, let the goroutines run forever. Fixes #38595 Change-Id: I4cd611fd7565f6e8d91e50c9273d91c514825314 Reviewed-on: https://go-review.googlesource.com/c/go/+/229484 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2020-04-22runtime: crash on SI_USER SigPanic signalIan Lance Taylor
Clean up the code a little bit to make it clearer: Don't check throwsplit for a SI_USER signal. If throwsplit is set for a SigPanic signal, always throw; discard any other flags. Fixes #36420 Change-Id: Ic9dcd1108603d241f71c040504dfdc6e528f9767 Reviewed-on: https://go-review.googlesource.com/c/go/+/228900 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2020-03-26runtime: fix threshold calculation of TestPhysicalMemoryUtilizationXiangdong Ji
Variable 'procs' used to calculate the threshold of overuse in TestPhysicalMemoryUtilization should be updated if GOMAXPROCS gets changed, otherwise the threshold could be a large number, making the test meaningless. Change-Id: I876cbf11457529f56bae77af1e35f4538a721f95 Reviewed-on: https://go-review.googlesource.com/c/go/+/210297 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2020-03-17runtime: don't report a pointer alignment error for pointer-free base typeKeith Randall
Fixes #37298 Change-Id: I8ba9c8b106e16cea7dd25473c7390b0f2ba9a1a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/223781 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-03-03runtime: during panic, print value instead of address, if kind is printableEmmanuel T Odeke
Make panics more useful by printing values, if their underlying kind is printable, instead of just their memory address. Thus now given any custom type derived from any of: float*, int*, string, uint* if we have panic with such a result, its value will be printed. Thus given any of: type MyComplex128 complex128 type MyFloat64 float64 type MyString string type MyUintptr uintptr panic(MyComplex128(32.1 + 10i)) panic(MyFloat64(-93.7)) panic(MyString("This one")) panic(MyUintptr(93)) They will now print in the panic: panic: main.MyComplex64(+1.100000e-001+3.000000e+000i) panic: main.MyFloat64(-9.370000e+001) panic: main.MyString("This one") panic: main.MyUintptr(93) instead of: panic: (main.MyComplex128) (0xe0100,0x138cc0) panic: (main.MyFloat64) (0xe0100,0x138068) panic: (main.MyString) (0x48aa00,0x4c0840) panic: (main.MyUintptr) (0xe0100,0x137e58) and anything else will be printed as in the past with: panic: (main.MyStruct) (0xe4ee0,0x40a0e0) Also while here, updated the Go1.15 release notes. Fixes #37531 Change-Id: Ia486424344a386014f2869ab3483e42a9ef48ac4 Reviewed-on: https://go-review.googlesource.com/c/go/+/221779 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-02-29runtime: do not exit(2) if a Go built DLL receives a signalmartin
Fixes #35965 Change-Id: I172501fc0b29595e59b058f6e30f31efe5f6d1f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/211139 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2020-01-10runtime: add tests for checkptrMatthew Dempsky
We had a few test cases to make sure checkptr didn't have certain false positives, but none to test for any true positives. This CL fixes that. Updates #22218. Change-Id: I24c02e469a4af43b1748829a9df325ce510f7cc4 Reviewed-on: https://go-review.googlesource.com/c/go/+/214238 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2019-12-06cmd/compile: mark empty block preemptibleCherry Zhang
Currently, a block's control instruction gets the liveness info of the last Value in the block. However, for an empty block, the control instruction gets the invalid liveness info and therefore not preemptible. One example is empty infinite loop, which has only a control instruction. The control instruction being non- preemptible makes the whole loop non-preemptible. Fix this by using a different, preemptible liveness info for empty block's control. We can choose an arbitrary preemptible liveness info, as at run time we don't really use the liveness map at that instruction. As before, if the last Value in the block is non-preemptible, so is the block control. For example, the conditional branch in the write barrier test block is still non-preemptible. Also, only update liveness info if we are actually emitting instructions. So zero-width Values' liveness info (which are always invalid) won't affect the block control's liveness info. For example, if the last Values in a block is a tuple-generating operation and a Select, the block control instruction is still preemptible. Fixes #35923. Change-Id: Ic5225f3254b07e4955f7905329b544515907642b Reviewed-on: https://go-review.googlesource.com/c/go/+/209659 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2019-11-22runtime: increase TestPhysicalMemoryUtilization thresholdMichael Anthony Knyszek
TestPhysicalMemoryUtilization occasionally fails on some platforms by only a small margin. The reason for this is that it assumes the scavenger will always be able to scavenge all the memory that's released by sweeping, but because of the page cache, there could be free and unscavenged memory held onto by a P which the scavenger simply cannot get to. As a result, if the page cache gets filled completely (512 KiB of free and unscavenged memory) this could skew a test which expects to scavenge roughly 8 MiB of memory. More specifically, this is 512 KiB of memory per P, and if a system is more inclined to bounce around between Ps (even if there's only one goroutine), this memory can get "stuck". Through some experimentation, I found that failures correlated highly with relatively large amounts of memory ending up in some page cache (like 60 or 64 pages) on at least one P. This change changes the test's threshold such that it accounts for the page cache, and scales up with GOMAXPROCS. Because the test constants themselves don't change, however, the test must now also bound GOMAXPROCS such that the threshold doesn't get too high (at which point the test becomes meaningless). Fixes #35580. Change-Id: I6bdb70706de991966a9d28347da830be4a19d3a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/208377 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-11-21runtime: relax TestAsyncPreemptCherry Zhang
In TestAsyncPreempt, the function being tested for preemption, although still asynchronously preemptible, may have only samll ranges of PCs that are preemtible. In an unlucky run, it may take quite a while to have a signal that lands on a preemptible instruction. The test case is kind of an extreme. Relax it to make it more preemptible. In the original version, the first closure has more work to do, and it is not a leaf function, and the second test case is a frameless leaf function. In the current version, the first one is also a frameless leaf function (the atomic is intrinsified). Add some calls to it. It is still not preemptible without async preemption. Fixes #35608. Change-Id: Ia4f857f2afc55501c6568d7507b517e3b4db191c Reviewed-on: https://go-review.googlesource.com/c/go/+/208221 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-11-05runtime: test a frameless function for async preemptionCherry Zhang
Frameless function is an interesting case for call injection espcially for LR architectures. Extend the test for this case. Change-Id: I074090d09eeaf642e71e3f44fea216f66d39b817 Reviewed-on: https://go-review.googlesource.com/c/go/+/202339 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2019-11-04runtime: ensure that Goexit cannot be aborted by a recursive panic/recoverDan Scales
When we do a successful recover of a panic, we resume normal execution by returning from the frame that had the deferred call that did the recover (after executing any remaining deferred calls in that frame). However, suppose we have called runtime.Goexit and there is a panic during one of the deferred calls run by the Goexit. Further assume that there is a deferred call in the frame of the Goexit or a parent frame that does a recover. Then the recovery process will actually resume normal execution above the Goexit frame and hence abort the Goexit. We will not terminate the thread as expected, but continue running in the frame above the Goexit. To fix this, we explicitly create a _panic object for a Goexit call. We then change the "abort" behavior for Goexits, but not panics. After a recovery, if the top-level panic is actually a Goexit that is marked to be aborted, then we return to the Goexit defer-processing loop, so that the Goexit is not actually aborted. Actual code changes are just panic.go, runtime2.go, and funcid.go. Adjusted the test related to the new Goexit behavior (TestRecoverBeforePanicAfterGoexit) and added several new tests of aborted panics (whose behavior has not changed). Fixes #29226 Change-Id: Ib13cb0074f5acc2567a28db7ca6912cfc47eecb5 Reviewed-on: https://go-review.googlesource.com/c/go/+/200081 Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2019-11-02runtime: add a test for asynchronous safe pointsAustin Clements
This adds a test of preempting a loop containing no synchronous safe points for STW and stack scanning. We couldn't add this test earlier because it requires scheduler, STW, and stack scanning preemption to all be working. For #10958, #24543. Change-Id: I73292db78ca3d14aab11bdafd26d03986920ef0a Reviewed-on: https://go-review.googlesource.com/c/go/+/201777 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-10-09all: remove the nacl port (part 1)Brad Fitzpatrick
You were a useful port and you've served your purpose. Thanks for all the play. A subsequent CL will remove amd64p32 (including assembly files and toolchain bits) and remaining bits. The amd64p32 removal will be separated into its own CL in case we want to support the Linux x32 ABI in the future and want our old amd64p32 support as a starting point. Updates #30439 Change-Id: Ia3a0c7d49804adc87bf52a4dea7e3d3007f2b1cd Reviewed-on: https://go-review.googlesource.com/c/go/+/199499 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-10-02os/signal: lazily start signal watch loop only on NotifyEmmanuel T Odeke
By lazily starting the signal watch loop only on Notify, we are able to have deadlock detection even when "os/signal" is imported. Thanks to Ian Lance Taylor for the solution and discussion. With this change in, fix a runtime gorountine count test that assumed that os/signal.init would unconditionally start the signal watching goroutine, but alas no more. Fixes #21576. Change-Id: I6eecf82a887f59f2ec8897f1bcd67ca311ca42ff Reviewed-on: https://go-review.googlesource.com/c/go/+/101036 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-09-25misc, runtime, test: extra tests and benchmarks for deferDan Scales
Add a bunch of extra tests and benchmarks for defer, in preparation for new low-cost (open-coded) implementation of defers (see #34481), - New file defer_test.go that tests a bunch more unusual defer scenarios, including things that might have problems for open-coded defers. - Additions to callers_test.go actually verifying what the stack trace looks like for various panic or panic-recover scenarios. - Additions to crash_test.go testing several more crash scenarios involving recursive panics. - New benchmark in runtime_test.go measuring speed of panic-recover - New CGo benchmark in cgo_test.go calling from Go to C back to Go that shows defer overhead Updates #34481 Change-Id: I423523f3e05fc0229d4277dd00073289a5526188 Reviewed-on: https://go-review.googlesource.com/c/go/+/197017 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Austin Clements <austin@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 00:17:28 +0000