aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/crash_test.go
AgeCommit message (Collapse)Author
2023-02-02runtime: eliminate arbitrary timeout in TestCgoLockOSThreadExitBryan C. Mills
This test previously failed if running a new pthread took longer than a hard-coded 100ms. On some slow or heavily-loaded builders, that scheduling latency is too short. Since the point of this test is to verify that the background thread is not reused after it terminates (see #20395), the arbitrary time limit does not seem helpful: if the background thread fails to terminate the test will time out on its own, and if the main goroutine is scheduled on the background thread the test will fail regardless of how long it takes. Fixes #58247. Change-Id: I626af52aac55af7a4c0e7829798573c479750c20 Reviewed-on: https://go-review.googlesource.com/c/go/+/464735 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-11-04runtime: eliminate arbitrary timeouts in runBuiltTestProg and TestGdbBacktraceBryan C. Mills
This may fix the TestEINTR failures that have been frequent on the riscv64 builders since CL 445597. Updates #37405. Updates #39043. Change-Id: Iaf1403ff5ce2ff0203d5d0059908097d32d0b217 Reviewed-on: https://go-review.googlesource.com/c/go/+/447495 Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Bryan Mills <bcmills@google.com>
2022-11-01runtime: check for ErrWaitDelay in runBuiltTestProgBryan C. Mills
ErrWaitDelay is not expected to occur in this test, but if it does it indicates a failure mode very different from the “failed to start” catchall that we log for other non-ExitError errors. Updates #50436. Change-Id: I3f4d87d502f772bf471fc17303d5a6b483446f8f Reviewed-on: https://go-review.googlesource.com/c/go/+/446876 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com>
2022-10-31internal/testenv: remove RunWithTimoutBryan C. Mills
For most tests, the test's deadline itself is more appropriate than an arbitrary timeout layered atop of it (especially once #48157 is implemented), and testenv.Command already adds cleaner timeout behavior when a command would run too close to the test's deadline. That makes RunWithTimeout something of an attractive nuisance. For now, migrate the two existing uses of it to testenv.CommandContext, with a shorter timeout implemented using context.WithTimeout. As a followup, we may want to drop the extra timeouts from these invocations entirely. Updates #50436. Updates #37405. Change-Id: I16840fd36c0137b6da87ec54012b3e44661f0d08 Reviewed-on: https://go-review.googlesource.com/c/go/+/445597 Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-08-09runtime: gofmtCherry Mui
Add new line at the end of crash_test.go. Change-Id: I73c77666066b105e563215f34e7ede6c1d92226b Reviewed-on: https://go-review.googlesource.com/c/go/+/422299 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-08-08cmd/compile,runtime: panic when unsafe.Slice param is nil and > 0cuiweixie
Fixes #54092 Change-Id: Ib917922ed36ee5410e5515f812737203c44f46ae GitHub-Last-Rev: dfd0c3883cf8b10479d9c5b389baa1a04c52dd34 GitHub-Pull-Request: golang/go#54107 Reviewed-on: https://go-review.googlesource.com/c/go/+/419755 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-15runtime: don't discard value from panic while panickinghopehook
In issue #17671, there are a endless loop if printing the panic value panics, CL 30358 has fixed that. As issue #52257 pointed out, above change should not discard the value from panic while panicking. With this CL, when we recover from a panic in error.Error() or stringer.String(), and the recovered value is string, then we can print it normally. Fixes #52257 Change-Id: Icfcc4a1a390635de405eea04904b4607ae9e3055 Reviewed-on: https://go-review.googlesource.com/c/go/+/399874 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2022-03-07runtime: print goid when throwing in gentracebackMichael Pratt
This makes it easier to figure out where the crash is occurring. Change-Id: Ie1f78a360367090dcd61c61b2a55c34f3e2ff2eb Reviewed-on: https://go-review.googlesource.com/c/go/+/390034 Trust: David Chase <drchase@google.com> Reviewed-by: David Chase <drchase@google.com> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2021-12-13all: gofmt -w -r 'interface{} -> any' srcRuss Cox
And then revert the bootstrap cmd directories and certain testdata. And adjust tests as needed. Not reverting the changes in std that are bootstrapped, because some of those changes would appear in API docs, and we want to use any consistently. Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories when preparing the bootstrap copy. A few files changed as a result of running gofmt -w not because of interface{} -> any but because they hadn't been updated for the new //go:build lines. Fixes #49884. Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09 Reviewed-on: https://go-review.googlesource.com/c/go/+/368254 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-12-12testenv: abstract run-with-timeout into testenvAustin Clements
This lifts the logic to run a subcommand with a timeout in a test from the runtime's runTestProg into testenv. The implementation is unchanged in this CL. We'll improve it in a future CL. Currently, tests that run subcommands usually just timeout with no useful output if the subcommand runs for too long. This is a step toward improving this. For #37405. Change-Id: I2298770db516e216379c4c438e05d23cbbdda51d Reviewed-on: https://go-review.googlesource.com/c/go/+/370701 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2021-11-24runtime: skip TestTimePprof on illumosTobias Klauser
On illumos nanotime calls libc, like on the other systems for which TestTimePprof is skipped. For #43118 Change-Id: I370d3f098a261185920cb1e3e3402d16200e301a Reviewed-on: https://go-review.googlesource.com/c/go/+/366737 Trust: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-11-24runtime: skip TestTimePprof if nanotime calls libcIan Lance Taylor
Fixes #43118 Change-Id: I499bf335904e2b72a2a8876d0368fff5e69aa7fa Reviewed-on: https://go-review.googlesource.com/c/go/+/366759 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-11-17runtime: don't serialize all builds in testIan Lance Taylor
Permit a test whose program is already built to run immediately, rather than waiting for another test to complete its build. For #44422 Change-Id: I2d1b35d055ee4c4251f4caef3b52dccc82b71a1b Reviewed-on: https://go-review.googlesource.com/c/go/+/364654 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-05-10net, runtime: drop macOS 10.12 skip conditions in testsTobias Klauser
Go 1.17 requires macOS 10.13 or later. Thus, drop the special cases for the darwin-amd64-10_12 builder added in CL 202618. Updates #22019 Updates #23011 Updates #32919 Change-Id: Idef11c213dfb25fd002b7cda6d425cf2e26a2e06 Reviewed-on: https://go-review.googlesource.com/c/go/+/318329 Trust: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.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>
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-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-09all: enable more tests on macOS/ARM64Cherry Zhang
On macOS, we can do "go build", can exec, and have the source tree available, so we can enable more tests. Skip ones that don't work. Most of them are due to that it requires external linking (for now) and some tests don't work with external linking (e.g. runtime deadlock detection). For them, helper functions CanInternalLink/MustInternalLink are introduced. I still want to have internal linking implemented, but it is still a good idea to identify which tests don't work with external linking. Updates #38485. Change-Id: I6b14697573cf3f371daf54b9ddd792acf232f2f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/260719 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2020-10-02runtime: add debugging to TestTimePprofAustin Clements
We've seen timeouts of TestTimePprof, but the tracebacks aren't useful because goroutines are running on other threads. Add GOTRACEBACK=crash to catch these in the future. For #41120. Change-Id: I97318172ef78d0cbab10df5e4ffcbfeadff579e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/258802 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@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>
2019-11-27runtime: print more information on stack overflowCherry Zhang
Print the current SP and (old) stack bounds when the stack grows too large. This helps to identify the problem: whether a large stack is used, or something else goes wrong. For #35470. Change-Id: I34a4064d5c7280978391d835e171b90d06f87222 Reviewed-on: https://go-review.googlesource.com/c/go/+/207351 Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2019-11-06runtime: remove stale runtime check in testsDmitry Vyukov
The check is not relevant anymore. The comment claims that go run does not rebuild packages, but this is not true. And we use go build anyway. We may have added the check because without caching rebuilding everything starting from runtime for each test takes a while. But now we have caching. So from every side this check just adds code and pain. Change-Id: Ifbbb643724100622e5f9db884339b67cde4ba729 Reviewed-on: https://go-review.googlesource.com/c/go/+/202450 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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-10-22net: ignore or skip known-flaky localhost Dial operations on macOS 10.12 builderBryan C. Mills
Fixes #22019 Fixes #32919 Change-Id: I60bf6c69b18c3e2d78b494e54adc958fe40134da Reviewed-on: https://go-review.googlesource.com/c/go/+/202618 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@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>
2019-09-25runtime: gofmt after CL 192937Tobias Klauser
CL 192937 introduced some changes which weren't properly gofmt'ed. Do so now. Change-Id: I2d2d57ea8a79fb41bc4ca59fa23f12198d615fd8 Reviewed-on: https://go-review.googlesource.com/c/go/+/196812 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-11runtime: fix crash during VDSO calls on armYuichi Nishiwaki
As discussed in #32912, a crash occurs when go runtime calls a VDSO function (say __vdso_clock_gettime) and a signal arrives to that thread. Since VDSO functions temporarily destroy the G register (R10), Go functions asynchronously executed in that thread (i.e. Go's signal handler) can try to load data from the destroyed G, which causes segmentation fault. To fix the issue a guard is inserted in front of sigtrampgo, so that the control escapes from signal handlers without touching G in case the signal occurred in the VDSO context. The test case included in the patch is take from discussion in a relevant thread on github: https://github.com/golang/go/issues/32912#issuecomment-517874531. This patch not only fixes the issue on AArch64 but also that on 32bit ARM. Fixes #32912 Change-Id: I657472e54b7aa3c617fabc5019ce63aa4105624a GitHub-Last-Rev: 28ce42c4a02a060f08c1b0dd1c9a392123fd2ee9 GitHub-Pull-Request: golang/go#34030 Reviewed-on: https://go-review.googlesource.com/c/go/+/192937 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-03-26runtime: improve sigtramp on aix/ppc64 to handle SIGPROFClément Chigot
R14, R15 must be saved in sigtramp because they might be modified by Go code when a SIGPROF occurs. Fixes #28555 Change-Id: I573541f108d7d6aac8e60d33c649e5db943f3ef5 Reviewed-on: https://go-review.googlesource.com/c/go/+/169117 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-03-08internal/testenv: remove SetModVendorBryan C. Mills
It turns out not to be necessary. Russ expressed a preference for avoiding module fetches over making 'go mod tidy' work within std and cmd right away, so for now we will make the loader use the vendor directory for the standard library even if '-mod=vendor' is not set explicitly. Updates #30228 Change-Id: Idf7208e63da8cb7bfe281b93ec21b61d40334947 Reviewed-on: https://go-review.googlesource.com/c/go/+/166357 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-03-05all: add -mod=vendor to GOFLAGS in tests that execute 'go' commands within ↵Bryan C. Mills
std or cmd Updates #30228 Updates #30240 Updates #30241 Change-Id: Idc311ba77e99909318b5b86f8ef82d4878f73e47 Reviewed-on: https://go-review.googlesource.com/c/go/+/165378 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-02-13runtime: scan gp._panic in stack scanCherry Zhang
In runtime.gopanic, the _panic object p is stack allocated and referenced from gp._panic. With stack objects, p on stack is dead at the point preprintpanics runs. gp._panic points to p, but stack scan doesn't look at gp. Heap scan of gp does look at gp._panic, but it stops and ignores the pointer as it points to the stack. So whatever p points to may be collected and clobbered. We need to scan gp._panic explicitly during stack scan. To test it reliably, we introduce a GODEBUG mode "clobberfree", which clobbers the memory content when the GC frees an object. Fixes #30150. Change-Id: I11128298f03a89f817faa221421a9d332b41dced Reviewed-on: https://go-review.googlesource.com/c/161778 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2018-11-02all: skip unsupported tests on AIXClément Chigot
This commit skips tests which aren't yet supported on AIX. nosplit.go is disabled because stackGuardMultiplier is increased for syscalls. Change-Id: Ib5ff9a4539c7646bcb6caee159f105ff8a160ad7 Reviewed-on: https://go-review.googlesource.com/c/146939 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
2018-09-14runtime: use CleanCmdEnv in TestRuntimePanicIan Lance Taylor
This makes TestRuntimePanic keep most of the existing environment, just as the other runtime tests do. Change-Id: I7944abfeee292d41716dca14483134a50d75f081 Reviewed-on: https://go-review.googlesource.com/135376 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-07-08runtime: skip TestG0StackOverflow on AndroidAustin Clements
This test is skipped on Linux and should be skipped on Android for the same reason. Change-Id: I753c4788d935bd58874554b455c0d5be2315b794 Reviewed-on: https://go-review.googlesource.com/122585 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-07-08runtime: fix TestAbort on non-x86 archesAustin Clements
CL 122515 tightened TestAbort to look for breakpoint exceptions and not just general signal crashes, but this only applies on x86 arches. On non-x86 arches we use a nil pointer dereference to abort, so the test is now failing. This CL re-loosens TestAbort on non-x86 arches to only expect a signal traceback. Should fix the build on linux/arm, linux/arm64, linux/ppc64, and linux/s390x. Change-Id: I1065341180ab5ab4da63b406c641dcde93c9490b Reviewed-on: https://go-review.googlesource.com/122580 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-07-08runtime: fix TestAbort on Plan 9David du Colombier
Since CL 122515, TestAbort is failing on Plan 9 because there is no SIGTRAP signal on Plan 9, but a note containing the "sys: breakpoint" string. This change fixes the TestAbort test by handling the Plan 9 case. Fixes #26265. Change-Id: I2fae00130bcee1cf946d8cc9d147a77f951be390 Reviewed-on: https://go-review.googlesource.com/122464 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2018-07-07runtime: handle g0 stack overflows gracefullyAustin Clements
Currently, if the runtime overflows the g0 stack on Windows, it leads to an infinite recursion: 1. Something overflows the g0 stack bounds and calls morestack. 2. morestack determines it's on the g0 stack and hence cannot grow the stack, so it calls badmorestackg0 (which prints "fatal: morestack on g0") followed by abort. 3. abort performs an INT $3, which turns into a Windows _EXCEPTION_BREAKPOINT exception. 4. This enters the Windows sigtramp, which ensures we're on the g0 stack and calls exceptionhandler. 5. exceptionhandler has a stack check prologue, so it determines that it's out of stack and calls morestack. 6. goto 2 Fix this by making the exception handler avoid stack checks until it has ruled out an abort and by blowing away the stack bounds in lastcontinuehandler before we print the final fatal traceback (which itself involves a lot of stack bounds checks). Fixes #21382. Change-Id: Ie66e91f708e18d131d97f22b43f9ac26f3aece5a Reviewed-on: https://go-review.googlesource.com/120857 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
2018-07-07runtime: fix abort handling on WindowsAustin Clements
On Windows, the IP recorded in the breakpoint exception caused by runtime.abort is actually one byte after the INT3, unlike on UNIX OSes. Account for this in isgoexception. It turns out TestAbort was "passing" on Windows anyway because abort still caused a fatal panic, just not the one we were expecting. This CL tightens this test to check that the runtime specifically reports a breakpoint exception. Fixing this is related to #21382, since we use runtime.abort in reporting g0 stack overflows, and it's important that we detect this and not try to handle it. Change-Id: I66120944d138eb80f839346b157a3759c1019e34 Reviewed-on: https://go-review.googlesource.com/122515 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
2018-06-29runtime: throw if the runtime panics with out of bounds indexIan Lance Taylor
If the runtime code panics due to a bad index or slice expression, then throw instead of panicing. This will skip calls to recover and dump the entire runtime stack trace. The runtime should never panic due to an out of bounds index, and this will help with debugging if it does. For #24991 Updates #25201 Change-Id: I85a9feded8f0de914ee1558425931853223c0514 Reviewed-on: https://go-review.googlesource.com/121515 Reviewed-by: Austin Clements <austin@google.com>
2018-03-08runtime: ensure abort actually crashes the processAustin Clements
On all non-x86 arches, runtime.abort simply reads from nil. Unfortunately, if this happens on a user stack, the signal handler will dutifully turn this into a panicmem, which lets user defers run and which user code can even recover from. To fix this, add an explicit check to the signal handler that turns faults in abort into hard crashes directly in the signal handler. This has the added benefit of giving a register dump at the abort point. Change-Id: If26a7f13790745ee3867db7f53b72d8281176d70 Reviewed-on: https://go-review.googlesource.com/93661 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-03-07runtime: get traceback from VDSO codeIan Lance Taylor
Currently if a profiling signal arrives while executing within a VDSO the profiler will report _ExternalCode, which is needlessly confusing for a pure Go program. Change the VDSO calling code to record the caller's PC/SP, so that we can do a traceback from that point. If that fails for some reason, report _VDSO rather than _ExternalCode, which should at least point in the right direction. This adds some instructions to the code that calls the VDSO, but the slowdown is reasonably negligible: name old time/op new time/op delta ClockVDSOAndFallbackPaths/vDSO-8 40.5ns ± 2% 41.3ns ± 1% +1.85% (p=0.002 n=10+10) ClockVDSOAndFallbackPaths/Fallback-8 41.9ns ± 1% 43.5ns ± 1% +3.84% (p=0.000 n=9+9) TimeNow-8 41.5ns ± 3% 41.5ns ± 2% ~ (p=0.723 n=10+10) Fixes #24142 Change-Id: Iacd935db3c4c782150b3809aaa675a71799b1c9c Reviewed-on: https://go-review.googlesource.com/97315 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2018-01-22runtime: print hexdump on traceback failureAustin Clements
Currently, if anything goes wrong when printing a traceback, we simply cut off the traceback without any further diagnostics. Unfortunately, right now, we have a few issues that are difficult to debug because the traceback simply cuts off (#21431, #23484). This is an attempt to improve the debuggability of traceback failure by printing a diagnostic message plus a hex dump around the failed traceback frame when something goes wrong. The failures look like: goroutine 5 [running]: runtime: unexpected return pc for main.badLR2 called from 0xbad stack: frame={sp:0xc42004dfa8, fp:0xc42004dfc8} stack=[0xc42004d800,0xc42004e000) 000000c42004dea8: 0000000000000001 0000000000000001 000000c42004deb8: 000000c42004ded8 000000c42004ded8 000000c42004dec8: 0000000000427eea <runtime.dopanic+74> 000000c42004ded8 000000c42004ded8: 000000000044df70 <runtime.dopanic.func1+0> 000000c420001080 000000c42004dee8: 0000000000427b21 <runtime.gopanic+961> 000000c42004df08 000000c42004def8: 000000c42004df98 0000000000427b21 <runtime.gopanic+961> 000000c42004df08: 0000000000000000 0000000000000000 000000c42004df18: 0000000000000000 0000000000000000 000000c42004df28: 0000000000000000 0000000000000000 000000c42004df38: 0000000000000000 000000c420001080 000000c42004df48: 0000000000000000 0000000000000000 000000c42004df58: 0000000000000000 0000000000000000 000000c42004df68: 000000c4200010a0 0000000000000000 000000c42004df78: 00000000004c6400 00000000005031d0 000000c42004df88: 0000000000000000 0000000000000000 000000c42004df98: 000000c42004dfb8 00000000004ae7d9 <main.badLR2+73> 000000c42004dfa8: <00000000004c6400 00000000005031d0 000000c42004dfb8: 000000c42004dfd0 !0000000000000bad 000000c42004dfc8: >0000000000000000 0000000000000000 000000c42004dfd8: 0000000000451821 <runtime.goexit+1> 0000000000000000 000000c42004dfe8: 0000000000000000 0000000000000000 000000c42004dff8: 0000000000000000 main.badLR2(0x0) /go/src/runtime/testdata/testprog/badtraceback.go:42 +0x49 For #21431, #23484. Change-Id: I8718fc76ced81adb0b4b0b4f2293f3219ca80786 Reviewed-on: https://go-review.googlesource.com/89016 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2017-11-09cmd/go: implement per-package asmflags, gcflags, ldflags, gccgoflagsRuss Cox
It has always been problematic that there was no way to specify tool flags that applied only to the build of certain packages; it was only to specify flags for all packages being built. The usual workaround was to install all dependencies of something, then build just that one thing with different flags. Since the dependencies appeared to be up-to-date, they were not rebuilt with the different flags. The new content-based staleness (up-to-date) checks see through this trick, because they detect changes in flags. This forces us to address the underlying problem of providing a way to specify per-package flags. The solution is to allow -gcflags=pattern=flags, which means that flags apply to packages matching pattern, in addition to the usual -gcflags=flags, which is now redefined to apply only to the packages named on the command line. See #22527 for discussion and rationale. Fixes #22527. Change-Id: I6716bed69edc324767f707b5bbf3aaa90e8e7302 Reviewed-on: https://go-review.googlesource.com/76551 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
2017-10-31runtime: shorten tests in all.bashRuss Cox
This cuts 23 seconds from all.bash on my MacBook Pro. Change-Id: Ibc4d7c01660b9e9ebd088dd55ba993f0d7ec6aa3 Reviewed-on: https://go-review.googlesource.com/73991 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2017-10-31all: respect $GO_GCFLAGS during run.bashRuss Cox
If the go install doesn't use the same flags as the main build it can overwrite the installed standard library, leading to flakiness and slow future tests. Force uses of 'go install' etc to propagate $GO_GCFLAGS or disable them entirely, to avoid problems. As I understand it, the main place this happens is the ssacheck builder. If there are other uses that need to run some of the now-disabled tests we can reenable fixed tests in followup CLs. Change-Id: Ib860a253539f402f8a96a3c00ec34f0bbf137c9a Reviewed-on: https://go-review.googlesource.com/74470 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2017-10-11runtime: terminate locked OS thread if its goroutine exitsAustin Clements
runtime.LockOSThread is sometimes used when the caller intends to put the OS thread into an unusual state. In this case, we never want to return this thread to the runtime thread pool. However, currently exiting the goroutine implicitly unlocks its OS thread. Fix this by terminating the locked OS thread when its goroutine exits, rather than simply returning it to the pool. Fixes #20395. Change-Id: I3dcec63b200957709965f7240dc216fa84b62ad9 Reviewed-on: https://go-review.googlesource.com/46038 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2017-09-13cmd/compile: add TestIntendedInlining from runtimeDaniel Martí
Move it from the runtime package, as we will soon add more packages and functions for it to check. The test used the testEnv func, which cleaned certain environment variables from a command, so it was moved to internal/testenv under a more descriptive (and less ambiguous) name. Add a simple godoc to it too. For #21851. Change-Id: I6f39c1f23b45377718355fafe66ffd87047d8ab6 Reviewed-on: https://go-review.googlesource.com/63550 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
2017-06-07runtime: deflake TestPanicRaceIan Lance Taylor
The test is inherently racy, and for me fails about 0.05% of the time. So only fail the test if it fails ten times in a row. Fixes #20594 Change-Id: I3b3f7598f2196f7406f1a3937f38f21ff0c0e4b5 Reviewed-on: https://go-review.googlesource.com/45020 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-06-05runtime: delay exiting while panic is running deferred functionsIan Lance Taylor
Try to avoid a race between the main goroutine exiting and a panic occurring. Don't try too hard, to avoid hanging. Updates #3934 Fixes #20018 Change-Id: I57a02b6d795d2a61f1cadd137ce097145280ece7 Reviewed-on: https://go-review.googlesource.com/41052 Reviewed-by: Austin Clements <austin@google.com>
generated by cgit v1.3-5-g9baa (git 2.53.0) at 2026-04-17 12:54:11 +0000