aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/crash_test.go
AgeCommit message (Collapse)Author
2025-12-11runtime: add extra subtest layer to TestFinalizerOrCleanupDeadlockMichael Anthony Knyszek
Currently TestFinalizerOrCleanupDeadlock runs a bunch of tests for both cleanups and finalizers. However, it doesn't actually distinguish these two cases in the subtest names. This change adds another layer of subtest to distinguish them. For #76523. Change-Id: I18c2857e970cde43c18cbbcbc44e4d4ada3b2628 Reviewed-on: https://go-review.googlesource.com/c/go/+/728821 Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
2025-12-05runtime: reject any goroutine leak test failure that failed to executeMichael Anthony Knyszek
This is far more general than the regexp, which was necessary only because runTestProg doesn't return the error. This change makes runTestProg a wrapper function around a function that *does* return the error. For #76526. Change-Id: Ib3daa75eb0fe314a28a7a368474943ba470d0d4d Reviewed-on: https://go-review.googlesource.com/c/go/+/726525 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-11-18runtime: do not print recovered when double panic with the same valueYoulin Feng
Show the "[recovered, repanicked]" message only when it is repanicked after recovered. For the duplicated panics that not recovered, do not show this message. Fixes #76099 Change-Id: I87282022ebe44c6f6efbe3239218be4a2a7b1104 Reviewed-on: https://go-review.googlesource.com/c/go/+/716020 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2025-10-30runtime: prioritize panic output over racefiniMichael Anthony Knyszek
For some reason CL 646198 uncovered #3934 and #20018 again, but only in race mode. It turns out that because racefini does not return, and racefini is called early after main returns, we would not properly wait for a concurrent panic to complete. This would result in fairly consistent failures of TestPanicRace, which specifically looks for the panic output to appear if main concurrently exits. The important part of this change is that race mode will no longer have the bug described in #3934 and #20018. A byproduct, however, is that racefini is that we're essentially prioritizing the panic output over racefini in this scenario. If racefini were to reveal a latent race condition and fail, we'll prefer to surface the panic. Such a case is probably fine, because the panic is always an crashing, unrecoverable panic. For #3934. For #20018. Change-Id: I0674a75c918563c5ec4ee1eec057dfd096fcfbc8 Reviewed-on: https://go-review.googlesource.com/c/go/+/691795 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-10-30runtime: eliminate _PsyscallMichael Anthony Knyszek
This change eliminates the _Psyscall state by using synchronization on the G status _Gsyscall to make syscalls work instead. This removes an atomic Store and an atomic CAS on the syscall path, which reduces syscall and cgo overheads. It also simplifies the syscall paths quite a bit. The one danger with this change is that we have a new combination of states that was previously impossible. There are brief windows where it's possible to observe a goroutine in _Grunning but without a P. This change is careful to hide this detail from the execution tracer, but it may have unexpected effects in the rest of the runtime, making this change somewhat risky. goos: linux goarch: amd64 pkg: internal/runtime/cgobench cpu: AMD EPYC 7B13 │ before.out │ after.out │ │ sec/op │ sec/op vs base │ CgoCall-64 43.69n ± 1% 35.83n ± 1% -17.99% (p=0.002 n=6) CgoCallParallel-64 5.306n ± 1% 5.338n ± 1% ~ (p=0.132 n=6) Change-Id: I4551afc1eea0c1b67a0b2dd26b0d49aa47bf1fb8 Reviewed-on: https://go-review.googlesource.com/c/go/+/646198 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-10-02runtime,net/http/pprof: goroutine leak detection by using the garbage collectorVlad Saioc
Proposal #74609 Change-Id: I97a754b128aac1bc5b7b9ab607fcd5bb390058c8 GitHub-Last-Rev: 60f2a192badf415112246de8bc6c0084085314f6 GitHub-Pull-Request: golang/go#74622 Reviewed-on: https://go-review.googlesource.com/c/go/+/688335 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: t hepudds <thepudds1460@gmail.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-07-29internal/goexperiment: delete RangeFunc goexperimentCherry Mui
It is now always enabeld. The GOEXPERIMENT doesn't control anything. Remove. Change-Id: I50eb09f4537f90ec28152eb59a5a689127843fce Reviewed-on: https://go-review.googlesource.com/c/go/+/684838 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-29runtime, testing/synctest: breaking bubble isolation with Cond is fatalDamien Neil
sync.Cond.Wait is durably blocking. Waking a goroutine out of Cond.Wait from outside its bubble panics. Make this panic a fatal panic, since it leaves the notifyList in an inconsistent state. We could do some work to make this a recoverable panic, but the complexity doesn't seem worth the outcome. For #67434 Change-Id: I88874c1519c2e5c0063175297a9b120cedabcd07 Reviewed-on: https://go-review.googlesource.com/c/go/+/675617 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Damien Neil <dneil@google.com>
2025-05-21runtime: skip TestTimePprof on sanitizersMichael Pratt
This test asserts there is no external code, but the sanitizer runtimes are external code. Fixes #73783. Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-race Change-Id: I6a6a636cf93b7950e3ea35e00ec2eaf89911d712 Reviewed-on: https://go-review.googlesource.com/c/go/+/675296 Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-20runtime: skip testprogcgo tests in race mode on freebsdMichael Pratt
These were just enabled by https://go.dev/cl/643897, but freebsd unfortunately doesn't seem to support cgo + race mode by default. For #73788. Cq-Include-Trybots: luci.golang.try:gotip-freebsd-amd64-race Change-Id: I6a6a636c06176ca746548d0588283b1429d7c6d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/674160 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2025-05-19runtime: pass through -asan/-msan/-race to testprog testsMichael Pratt
The tests using testprog / testprogcgo are currently not covered on the asan/msan/race builders because they don't build testprog with the sanitizer flag. Explicitly pass the flag if the test itself is built with the sanitizer. There were a few tests that explicitly passed -race (even on non-race builders). These tests will now only run on race builders. For #71395. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15,gotip-linux-amd64-race Change-Id: I6a6a636ce8271246316a80d426c0e4e2f6ab99c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/643897 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2025-05-08runtime: schedule cleanups across multiple goroutinesMichael Anthony Knyszek
This change splits the finalizer and cleanup queues and implements a new lock-free blocking queue for cleanups. The basic design is as follows: The cleanup queue is organized in fixed-sized blocks. Individual cleanup functions are queued, but only whole blocks are dequeued. Enqueuing cleanups places them in P-local cleanup blocks. These are flushed to the full list as they get full. Cleanups can only be enqueued by an active sweeper. Dequeuing cleanups always dequeues entire blocks from the full list. Cleanup blocks can be dequeued and executed at any time. The very last active sweeper in the sweep phase is responsible for flushing all local cleanup blocks to the full list. It can do this without any synchronization because the next GC can't start yet, so we can be very certain that nobody else will be accessing the local blocks. Cleanup blocks are stored off-heap because the need to be allocated by the sweeper, which is called from heap allocation paths. As a result, the GC treats cleanup blocks as roots, just like finalizer blocks. Flushes to the full list signal to the scheduler that cleanup goroutines should be awoken. Every time the scheduler goes to wake up a cleanup goroutine and there were more signals than goroutines to wake, it then forwards this signal to runtime.AddCleanup, so that it creates another goroutine the next time it is called, up to gomaxprocs goroutines. The signals here are a little convoluted, but exist because the sweeper and the scheduler cannot safely create new goroutines. For #71772. For #71825. Change-Id: Ie839fde2b67e1b79ac1426be0ea29a8d923a62cc Reviewed-on: https://go-review.googlesource.com/c/go/+/650697 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2025-05-06runtime: replace mentions of "raised" with "panicked"Mark Freeman
Fixes #73526 Change-Id: I4b801cf3e54b99559e6d5ca8fdb2fd0692a0d3a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/669975 TryBot-Bypass: Mark Freeman <mark@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <mark@golang.org> Reviewed-by: Mark Freeman <mark@golang.org>
2025-03-24runtime: rename runfinq to runFinalizersAndCleanupsMichael Pratt
Users see this frame in tracebacks and it serves as a hint that what is running here is a finalizer or cleanup. But runfinq is a rather dense name. We can give it a more obvious name to help users realize what it is. For #73011. Change-Id: I6a6a636ce9a493fd00d4b4c60c23f2b1c96d3568 Reviewed-on: https://go-review.googlesource.com/c/go/+/660296 Auto-Submit: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-03-24runtime: always show runfinq in tracebackMichael Pratt
Today, runtime.runfinq is hidden whenever runtime frames are hidden. However this frame serves as a hint that this goroutine is running finalizers, which is otherwise unclear, but can be useful when debugging issues with finalizers. Fixes #73011. Change-Id: I6a6a636cb63951fbe1fefc3554fe9cea5d0a0fb6 Reviewed-on: https://go-review.googlesource.com/c/go/+/660295 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-02-25all: surround -test.run arguments with ^$qmuntal
If the -test.run value is not surrounded by ^$ then any test that matches the -test.run value will be run. This is normally not the desired behavior, as it can lead to unexpected tests being run. Change-Id: I3447aaebad5156bbef7f263cdb9f6b8c32331324 Reviewed-on: https://go-review.googlesource.com/c/go/+/651956 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-02-24all: use testenv.Executable instead of os.Executable and os.Args[0]qmuntal
In test files, using testenv.Executable is more reliable than os.Executable or os.Args[0]. Change-Id: I88e577efeabc20d02ada27bf706ae4523129128e Reviewed-on: https://go-review.googlesource.com/c/go/+/651955 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2025-02-07internal/trace: refactor how experimental batches are exposedMichael Anthony Knyszek
This change modifies how per-generation experimental batches are exposed. Rather than expose them on the ExperimentalEvent, it exposes it as part of the Sync event, so it's clear to the caller when the information becomes relevant and when it should be parsed. This change also adds a field to each ExperimentalEvent indicating which experiment the event is a part of. Because this information needs to appear *before* a generation is observed, we now ensure there is a sync event both before and after each generation. This means the final sync event is now a special case; previously we would only emit a sync event after each generation. This change is based on feedback from Austin Clements on the experimental events functionality. For #62627. Change-Id: I48b0fe12b22abb7ac8820a9e73447bfed8419856 Reviewed-on: https://go-review.googlesource.com/c/go/+/644215 Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-02-06runtime: don't duplicate reraised panic values in printpanicsDamien Neil
Change the output printed when crashing with a reraised panic value to not duplicate that value. Changes output of panicking with "PANIC", recovering, and reraising from: panic: PANIC [recovered] panic: PANIC to: panic: PANIC [recovered, reraised] Fixes #71517 Change-Id: Id59938c4ea0df555b851ffc650fe6f94c0845499 Reviewed-on: https://go-review.googlesource.com/c/go/+/645916 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-12-19runtime: test trap panic parsing in TestTracebackSystemMichael Pratt
This mirrors https://go.dev/cl/637755, as x/telemetry is now aware of sigpanic preceding trap frames. For #70637. Change-Id: I13a775f25e89047702d4f2d463ce3210bcf192d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/638015 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-10-30internal/runtime/maps: proper capacity hint handlingMichael Pratt
When given a hint size, set the initial capacity large enough to avoid requiring growth in the average case. When not given a hint (or given 0), don't allocate anything at all. For #54766. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-swissmap Change-Id: I8844fc652b8d2d4e5136cd56f7e78999a07fe381 Reviewed-on: https://go-review.googlesource.com/c/go/+/616457 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2024-09-25runtime: print fatal messages without interleavingKeith Randall
Grab the print lock around the set of prints we use to report fatal errors. This ensures that each fatal error gets reported atomically instead of interleaved with other fatal errors. Fixes #69447 Change-Id: Ib3569f0c8210fd7e19a7d8ef4bc114f07469f317 Reviewed-on: https://go-review.googlesource.com/c/go/+/615655 Auto-Submit: Keith Randall <khr@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-05-17runtime: fix coro interactions with thread-locked goroutinesMichael Anthony Knyszek
This change fixes problems with thread-locked goroutines using newcoro/coroswitch/etc. Currently, the coro paths do not consider thread-locked goroutines at all and can quickly result in broken scheduler state or lost/leaked goroutines. One possible fix to these issues is to fall back on goroutine+channel semantics, but that turns out to be fairly complicated to implement and results in significant performance cliffs. More complex thread-lock state donation tricks also result in some fairly complicated state tracking that doesn't seem worth it given the use-cases of iter.Pull (and even then, there will be performance cliffs). This change implements a much simpler, but more restrictive semantics. In particular, thread-lock state is tied to the coro at the first call to newcoro (i.e. iter.Pull). From then on, the invariant is that if the coro has any thread-lock state *or* a goroutine calling into coroswitch has any thread-lock state, that the full gamut of thread-lock state must remain the same as it was when newcoro was called (the full gamut meaning internal and external lock counts as well as the identity of the thread that was locked to). This semantics allows the common cases to be always fast, but comes with a non-orthogonality caveat. Specifically, when iter.Pull is used in conjunction with thread-locked goroutines, complex cases (passing next between goroutines or passing yield between goroutines) are likely to fail. Simple cases, where any number of iter.Pull iterators are used in a straightforward way (nested, in series, etc.) from the same goroutine, will work and will be guaranteed to be fast regardless of thread-lock state. This is a compromise for the near-term and we may consider lifting the restrictions imposed by this CL in the future. Fixes #65889. Fixes #65946. Change-Id: I3fb5791e36a61f5ded50226a229a79d28739b24e Reviewed-on: https://go-review.googlesource.com/c/go/+/583675 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Austin Clements <austin@google.com>
2024-05-17internal/trace: move v2 tracer into trace directoryCarlos Amedee
This change moves the v2 tracer into the trace directory. Updates #67367 Change-Id: I3657b4227002cb00fdf29c797434800ea796715e Reviewed-on: https://go-review.googlesource.com/c/go/+/584538 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-05-08runtime: properly frame panic values in tracebacksAlan Donovan
This CL causes the printing of panic values to ensure that all newlines in the output are immediately followed by a tab, so that there is no way for a maliciously crafted panic value to fool a program attempting to parse the traceback into thinking that the panic value is in fact a goroutine stack. See https://github.com/golang/go/issues/64590#issuecomment-1932675696 + release note Updates #64590 Updates #63455 Change-Id: I5142acb777383c0c122779d984e73879567dc627 Reviewed-on: https://go-review.googlesource.com/c/go/+/581215 Auto-Submit: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2024-04-15runtime, cmd/trace: remove code paths that include v1 tracerCarlos Amedee
This change makes the new execution tracer described in #60773, the default tracer. This change attempts to make the smallest amount of changes for a single CL. Updates #66703 For #60773 Change-Id: I3742f3419c54f07d7c020ae5e1c18d29d8bcae6d Reviewed-on: https://go-review.googlesource.com/c/go/+/576256 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-04-10runtime: push down systemstack requirement for tracer where possibleMichael Anthony Knyszek
Currently lots of functions require systemstack because the trace buffer might get flushed, but that will already switch to the systemstack for the most critical bits (grabbing trace.lock). That means a lot of this code is non-preemptible when it doesn't need to be. We've seen this cause problems at scale, when dumping very large numbers of stacks at once, for example. This is a re-land of CL 572095 which was reverted in CL 577376. This re-land includes a fix of the test that broke on the longtest builders. Change-Id: Ia8d7cbe3aaa8398cf4a1818bac66c3415a399348 Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/577377 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2024-03-15runtime: allow omitting virtual PCs from runtime.CallersFrames inputRuss Cox
This makes CL 561635's test pass without any changes to the traceback textual format. The test in this CL is copied identically from CL 561635. Change-Id: I5130abdfefd9940f98f20c283cca6cd159e37617 Reviewed-on: https://go-review.googlesource.com/c/go/+/571798 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-03-14runtime: revert "traceback: include pc=0x%x for inline frames"Russ Cox
This reverts commit 643d816c8b43 (CL 561635). Reason for revert: This works for telemetry but broke various other properties of the tracebacks as well as some programs that read tracebacks. We should figure out a solution that works for all uses, and in the interim we should not be making telemetry work at the cost of breaking other, existing valid uses. See #65761 for details. Change-Id: I467993ae778887e5bd3cca4c0fb54e9d44802ee1 Reviewed-on: https://go-review.googlesource.com/c/go/+/571797 Auto-Submit: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-02-10runtime: call traceAdvance before exitingNicolas Hillegeer
This ensures the trace buffers are as up-to-date as possible right before crashing. It increases the chance of finding the culprit for the crash when looking at core dumps, e.g. if slowness is the cause for the crash (monitor kills process). Fixes #65319. Change-Id: Iaf5551911b3b3b01ba65cb8749cf62a411e02d9c Reviewed-on: https://go-review.googlesource.com/c/go/+/562616 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-02-08runtime: traceback: include pc=0x%x for inline framesAlan Donovan
Crash monitoring tools may parse the PC values and feed them to CallersFrames, which does not run the inline unwinder, since Callers already did so. So, the GOTRACEBACK=system output must also include PC values even for inlined frames. (The actual values are just marker NOP instructions, but that isn't important.) This CL also includes a test that the PC values can be parsed out of the crash report and fed to CallersFrames to yield a sensible result. (The logic is a distillation of the x/telemetry crashmonitor.) The previously printed PCs were in fact slightly wrong for frames containing inlined calls: instead of the virtual CALL instruction (a NOP) to the first inlined call, it would display the PC of the CALL in the innermost inlined function. Change-Id: I64a06771fc191ba16c1383b8139b714f4f299703 Reviewed-on: https://go-review.googlesource.com/c/go/+/561635 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-01-30runtime: print exported methods from the runtime in tracebacksKeith Randall
We currently suppress runtime frames in tracebacks, except for exported functions. This CL also prints exported methods of exported types in tracebacks, for consistency. Change-Id: Ic65e7611621f0b210de5ae0c02b9d0a044f39fd6 Reviewed-on: https://go-review.googlesource.com/c/go/+/507736 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
2023-11-21runtime: disable crash stack on WindowsCherry Mui
Apparently, on Windows, throwing an exception on a non-system- allocated crash stack causes EXCEPTION_STACK_OVERFLOW and hangs the process (see issue #63938). Disable crash stack for now, which gets us back the the behavior of Go 1.21. Fixes #63938. Change-Id: I4c090315b93b484e756b242f0de7a9e02f199261 Reviewed-on: https://go-review.googlesource.com/c/go/+/543996 Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
2023-11-09runtime: skip TestG0StackOverflow on windows/arm64Cherry Mui
Temporarily skip to make the builder happy. Will work on a fix. Updates #63938. Change-Id: Ic9db771342108430c29774b2c3e50043791189a6 Reviewed-on: https://go-review.googlesource.com/c/go/+/541195 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com>
2023-11-02runtime: add crash stack support for riscv64Joel Sing
Change-Id: Ib89a71e20f9c6b86c97814c75cb427e9bd7075e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/538735 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Joel Sing <joel@sing.id.au>
2023-10-31runtime: use testenv.Command in TestG0StackOverflowCherry Mui
For debugging timeouts. Change-Id: I08dc86ec0264196e5fd54066655e94a9d062ed80 Reviewed-on: https://go-review.googlesource.com/c/go/+/538697 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2023-10-26runtime: print a stack trace at "morestack on g0"Cherry Mui
Error like "morestack on g0" is one of the errors that is very hard to debug, because often it doesn't print a useful stack trace. The runtime doesn't directly print a stack trace because it is a bad stack state to call print. Sometimes the SIGABRT may trigger a traceback, but sometimes not especially in a cgo binary. Even if it triggers a traceback it often does not include the stack trace of the bad stack. This CL makes it explicitly print a stack trace and throw. The idea is to have some space as an "emergency" crash stack. When the stack is in a really bad state, we switch to the crash stack and do a traceback. Currently only implemented on AMD64 and ARM64. TODO: also handle errors like "morestack on gsignal" and bad systemstack. Also handle other architectures. Change-Id: Ibfc397202f2bb0737c5cbe99f2763de83301c1c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/419435 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-09-18runtime: skip TestG0StackOverflow on iOSCherry Mui
Apparently it falls into infinite printing loop. Skipping for now. Will investigate. For #62671. Change-Id: I5be8e8c1d0f4f2eaa231d6bcdfe13e7f08c28b98 Reviewed-on: https://go-review.googlesource.com/c/go/+/528403 Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Run-TryBot: Bryan Mills <bcmills@google.com>
2023-09-08runtime: unskip TestG0StackOverflowCherry Mui
The stack bounds from pthread are not always accurate, and could cause seg fault if we run out of the actual stack space before reaching the bounds. Here we use an artificially small stack bounds to check overflow without actually running out of the system stack. Change-Id: I8067c5e1297307103b315d9d0c60120293b57aab Reviewed-on: https://go-review.googlesource.com/c/go/+/523695 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-09-05all: use ^TestName$ regular pattern for invoking a single testDmitri Shuralyov
Use ^ and $ in the -run flag regular expression value when the intention is to invoke a single named test. This removes the reliance on there not being another similarly named test to achieve the intended result. In particular, package syscall has tests named TestUnshareMountNameSpace and TestUnshareMountNameSpaceChroot that both trigger themselves setting GO_WANT_HELPER_PROCESS=1 to run alternate code in a helper process. As a consequence of overlap in their test names, the former was inadvertently triggering one too many helpers. Spotted while reviewing CL 525196. Apply the same change in other places to make it easier for code readers to see that said tests aren't running extraneous tests. The unlikely cases of -run=TestSomething intentionally being used to run all tests that have the TestSomething substring in the name can be better written as -run=^.*TestSomething.*$ or with a comment so it is clear it wasn't an oversight. Change-Id: Iba208aba3998acdbf8c6708e5d23ab88938bfc1e Reviewed-on: https://go-review.googlesource.com/c/go/+/524948 Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Kirill Kolyshkin <kolyshkin@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-09-05runtime: don't let the tests leave core files behindIan Lance Taylor
Also add a check that we didn't leave any core files behind. Change-Id: I30444ef43ad1a8cc1cacd3b75280f2128e104939 Reviewed-on: https://go-review.googlesource.com/c/go/+/525175 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2023-07-18runtime: decrement netpollWaiters in netpollunblockIan Lance Taylor
We used to decrement it in netpollgoready, but that missed the common case of a descriptor becoming ready due to I/O. All calls to netpollgoready go through netpollunblock, so this shouldn't miss any decrements we missed before. Fixes #60782 Change-Id: Ideefefa1ac96ca38e09fe2dd5d595c5dd7883237 Reviewed-on: https://go-review.googlesource.com/c/go/+/503923 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2023-07-06runtime: print output on failure in TestMemPprofCherry Mui
If running testprog fails, print the output. For #60901. Change-Id: Iee80fb09412ce13bae6ac3589779a8cdf7761765 Reviewed-on: https://go-review.googlesource.com/c/go/+/507978 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com>
2023-04-21runtime: skip TestG0StackOverflow on iosBryan C. Mills
This test fails when run on ios. (Although ios does not normally support "exec", in the corellium environment it does.) For #26061. Change-Id: Idfdc53758aaabf0cb87ae50f9a4666deebf57fd6 Reviewed-on: https://go-review.googlesource.com/c/go/+/487355 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Bryan Mills <bcmills@google.com>
2023-03-02cmd/link/internal/ld: move more of mustLinkExternal into internal/platformBryan C. Mills
internal/platform.MustLinkExternal is used in various places to determine whether external linking is required. It should always match what the linker actually requires, but today does not match because the linker imposes additional constraints. Updates #31544. Change-Id: I0cc6ad587e95c607329dea5d60d29a5fb2a9e722 Reviewed-on: https://go-review.googlesource.com/c/go/+/472515 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 09:23:56 +0000