aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/testdata
AgeCommit message (Collapse)Author
2023-04-03runtime/cgo: store M for C-created thread in pthread keydoujiang24
This reapplies CL 392854, with the followup fixes in CL 479255, CL 479915, and CL 481057 incorporated. CL 392854, by doujiang24 <doujiang24@gmail.com>, speed up C to Go calls by binding the M to the C thread. See below for its description. CL 479255 is a followup fix for a small bug in ARM assembly code. CL 479915 is another followup fix to address C to Go calls after the C code uses some stack, but that CL is also buggy. CL 481057, by Michael Knyszek, is a followup fix for a memory leak bug of CL 479915. [Original CL 392854 description] In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls. So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call. Instead, we only dropm while the C thread exits, so the extra M won't leak. When invoking a Go function from C: Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor. And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits. When returning back to C: Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C. This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows. This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread. For the newly added BenchmarkCGoInCThread, some benchmark results: 1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz [CL 479915 description] Currently, when C calls into Go the first time, we grab an M using needm, which sets m.g0's stack bounds using the SP. We don't know how big the stack is, so we simply assume 32K. Previously, when the Go function returns to C, we drop the M, and the next time C calls into Go, we put a new stack bound on the g0 based on the current SP. After CL 392854, we don't drop the M, and the next time C calls into Go, we reuse the same g0, without recomputing the stack bounds. If the C code uses quite a bit of stack space before calling into Go, the SP may be well below the 32K stack bound we assumed, so the runtime thinks the g0 stack overflows. This CL makes needm get a more accurate stack bound from pthread. (In some platforms this may still be a guess as we don't know exactly where we are in the C stack), but it is probably better than simply assuming 32K. Fixes #51676. Fixes #59294. Change-Id: I9bf1400106d5c08ce621d2ed1df3a2d9e3f55494 Reviewed-on: https://go-review.googlesource.com/c/go/+/481061 Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: DeJiang Zhu (doujiang) <doujiang24@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-31Revert "runtime/cgo: store M for C-created thread in pthread key"Cherry Mui
This reverts CL 392854. Reason for revert: caused #59294, which was derived from google internal tests. The attempted fix of #59294 caused more breakage. Change-Id: I5a061561ac2740856b7ecc09725ac28bd30f8bba Reviewed-on: https://go-review.googlesource.com/c/go/+/481060 Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-30runtime/trace: use regular unwinding for cgo callbacksFelix Geisendörfer
Introduce a new m.incgocallback field that is true while C code calls into Go code. Use it in the tracer in order to fallback to the default unwinder instead of frame pointer unwinding for this scenario. The existing fields (incgo, ncgo) were not sufficient to detect the case where a thread created in C calls into Go code. Motivation: 1. Take advantage of a cgo symbolizer, if registered, to unwind through C stacks without frame pointers. 2. Reduce the chance of crashes. It seems unsafe to follow frame pointers when there could be C code that was compiled without frame pointers. Removing the curgp.m.incgocallback check in traceStackID shows the following minor differences between frame pointer unwinding and the default unwinder when there is no cgo symbolizer involved. trace_test.go:60: "goCalledFromCThread": got stack: main.goCalledFromCThread /src/runtime/testdata/testprogcgo/trace.go:58 _cgoexp_45c15a3efb3a_goCalledFromCThread _cgo_gotypes.go:694 runtime.cgocallbackg1 /src/runtime/cgocall.go:318 runtime.cgocallbackg /src/runtime/cgocall.go:236 runtime.cgocallback /src/runtime/asm_amd64.s:998 crosscall2 /src/runtime/cgo/asm_amd64.s:30 want stack: main.goCalledFromCThread /src/runtime/testdata/testprogcgo/trace.go:58 _cgoexp_45c15a3efb3a_goCalledFromCThread _cgo_gotypes.go:694 runtime.cgocallbackg1 /src/runtime/cgocall.go:318 runtime.cgocallbackg /src/runtime/cgocall.go:236 runtime.cgocallback /src/runtime/asm_amd64.s:998 trace_test.go:60: "goCalledFromC": got stack: main.goCalledFromC /src/runtime/testdata/testprogcgo/trace.go:51 _cgoexp_45c15a3efb3a_goCalledFromC _cgo_gotypes.go:687 runtime.cgocallbackg1 /src/runtime/cgocall.go:318 runtime.cgocallbackg /src/runtime/cgocall.go:236 runtime.cgocallback /src/runtime/asm_amd64.s:998 crosscall2 /src/runtime/cgo/asm_amd64.s:30 runtime.asmcgocall /src/runtime/asm_amd64.s:848 main._Cfunc_cCalledFromGo _cgo_gotypes.go:263 main.goCalledFromGo /src/runtime/testdata/testprogcgo/trace.go:46 main.Trace /src/runtime/testdata/testprogcgo/trace.go:37 main.main /src/runtime/testdata/testprogcgo/main.go:34 want stack: main.goCalledFromC /src/runtime/testdata/testprogcgo/trace.go:51 _cgoexp_45c15a3efb3a_goCalledFromC _cgo_gotypes.go:687 runtime.cgocallbackg1 /src/runtime/cgocall.go:318 runtime.cgocallbackg /src/runtime/cgocall.go:236 runtime.cgocallback /src/runtime/asm_amd64.s:998 runtime.systemstack_switch /src/runtime/asm_amd64.s:463 runtime.cgocall /src/runtime/cgocall.go:168 main._Cfunc_cCalledFromGo _cgo_gotypes.go:263 main.goCalledFromGo /src/runtime/testdata/testprogcgo/trace.go:46 main.Trace /src/runtime/testdata/testprogcgo/trace.go:37 main.main /src/runtime/testdata/testprogcgo/main.go:34 For #16638 Change-Id: I95fa27a3170c5abd923afc6eadab4eae777ced31 Reviewed-on: https://go-review.googlesource.com/c/go/+/474916 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
2023-03-24runtime/cgo: store M for C-created thread in pthread keydoujiang24
In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls. So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call. Instead, we only dropm while the C thread exits, so the extra M won't leak. When invoking a Go function from C: Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor. And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits. When returning back to C: Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C. This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows. This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread. For the newly added BenchmarkCGoInCThread, some benchmark results: 1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz Fixes #51676 Change-Id: I380702fe2f9b6b401b2d6f04b0aba990f4b9ee6c GitHub-Last-Rev: 93dc64ad98e5583372e41f65ee4b7ab78b5aff51 GitHub-Pull-Request: golang/go#51679 Reviewed-on: https://go-review.googlesource.com/c/go/+/392854 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: thepudds <thepudds1460@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-03-07runtime: allow for 5 more threads in TestWindowsStackMemory*Alex Brainman
Original version of TestWindowsStackMemory did not consider sysmon and other threads running during the test. Allow for 5 extra threads in this test - this should cover any new threads in the future. Fixes #58570 Change-Id: I215790f9b94ff40a32ddd7aa54af715d1dc391c6 Reviewed-on: https://go-review.googlesource.com/c/go/+/473415 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-02-28runtime: use os.TempDir instead of hard-coding /tmpBryan C. Mills
On Android, /tmp does not exist. Change-Id: Ib1797d79d89704a7a9466ad94efd57d2848b3b57 Reviewed-on: https://go-review.googlesource.com/c/go/+/472255 TryBot-Bypass: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Bryan Mills <bcmills@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>
2023-01-24runtime: run TestVectoredHandlerDontCrashOnLibrary on 386 and arm64qmuntal
This CL updates TestVectoredHandlerDontCrashOnLibrary so it can run on windows/386 and windows/arm64. It still can't run on windows/arm as it does not support c-shared buildmode (see #43800). Change-Id: Id1577687e165e77d27633c632634ecf86e6e9d6f Reviewed-on: https://go-review.googlesource.com/c/go/+/463117 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2022-11-01runtime: fix missing error print in TestCgoSigfwdAustin Clements
The result of the call to fmt.Errorf was unused. It was clearly intending to print the message, not simply construct an error. Change-Id: I14856214c521a51fe4b45690e6c35fbb17e66577 Reviewed-on: https://go-review.googlesource.com/c/go/+/443375 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
2022-10-20runtime: fix TestVectoredHandlerExceptionInNonGoThreadqmuntal
This test is failing on the windows-arm64-10 builder https://build.golang.org/log/c161c86be1af83c349ee02c1b12eff5828818f50. It is not failing on windows-arm64-11, so I guess it has something to do with the compiler. This CL simplifies the test so is easier to build. Change-Id: I6e0e1cf237277628f8ebf892c70ab54cd0077680 Reviewed-on: https://go-review.googlesource.com/c/go/+/444438 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2022-10-19runtime: ignore exceptions from non-Go threads on windows arm/arm64qmuntal
If there is no current G while handling an exception it means the exception was originated in a non-Go thread. The best we can do is ignore the exception and let it flow through other vectored and structured error handlers. I've removed badsignal2 from sigtramp because we can't really know if the signal is bad or not, it might be handled later in the chain. Fixes #50877 Updates #56082 Change-Id: Ica159eb843629986d1fb5482f0b59a9c1ed91698 Reviewed-on: https://go-review.googlesource.com/c/go/+/442896 Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: David Chase <drchase@google.com>
2022-10-17runtime: run TestCgoSigfwd on all Unix platformsAustin Clements
This test was originally Linux-only, but there doesn't seem to be anything Linux-specific in it. Change-Id: I0f8519eff5dbed97f5e21e1c8e5ab0d747d51df3 Reviewed-on: https://go-review.googlesource.com/c/go/+/443073 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-10-17runtime: improve coverage of TestCgoSigfwdAustin Clements
Currently, TestCgoSigfwd will pass incorrectly if the SIGSEGV that originates in Go mistakenly goes to the C SIGSEGV handler. Fix this by adding a signal-atomic variable that tracks what the expected behavior is. Change-Id: Id2a9fa3b209299dccf90bb60720b89ad96838a9c Reviewed-on: https://go-review.googlesource.com/c/go/+/443072 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-10-17misc/cgo/testsigfwd: move to runtime/testprog/testprogcgoAustin Clements
This migrates testsigfwd, which uses some one-off build infrastructure, to be part of the runtime's testprogcgo. The test is largely unchanged. Because it's part of a larger binary, this CL renames a few things and gates the constructor-time signal handler registration on an environment variable. This CL also replaces an errant fmt.Errorf with fmt.Fprintf. For #37486, since it eliminates a non-go-test from dist. Change-Id: I0efd146ea0a0a3f0b361431349a419af0f0ecc61 Reviewed-on: https://go-review.googlesource.com/c/go/+/443068 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-10-02all: use time.Since instead of time.Now().Subhopehook
Change-Id: Ifaa73b64e5b6a1d37c753e2440b642478d7dfbce Reviewed-on: https://go-review.googlesource.com/c/go/+/436957 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: hopehook <hopehook@golangcn.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2022-09-30all: omit comparison bool constant to simplify codecui fliter
Change-Id: Icd4062e570559f1d0c69d4bdb9e23412054cf2a6 GitHub-Last-Rev: fbbfbcb54dac88c9a8f5c5c6d210be46f87e27dd GitHub-Pull-Request: golang/go#55958 Reviewed-on: https://go-review.googlesource.com/c/go/+/436880 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2022-09-30runtime/trace: skip tests if parsing fails with timestamp errordoujiang24
already skips tests in case of the timestamp error, eg. #97757 Change-Id: Ia696e83cba2e3ed50181a8100b964847092a7365 GitHub-Last-Rev: 8e5f607e14f6a15ed6da5f205c4ca67a4adb6fc8 GitHub-Pull-Request: golang/go#55918 Reviewed-on: https://go-review.googlesource.com/c/go/+/435855 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Joel Sing <joel@sing.id.au> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Michael Pratt <mpratt@google.com>
2022-09-27runtime: using bytes.CutPrefixcuiweixie
Change-Id: I3f2dae17496b5b4efbdc022802f941a616abd87a Reviewed-on: https://go-review.googlesource.com/c/go/+/435276 Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-27runtime/trace: add missing events for the locked g in extra M.doujiang24
Extra Ms may lead to the "no consistent ordering of events possible" error when parsing trace file with cgo enabled, since: 1. The gs in the extra Ms may be in `_Gdead` status while starting trace by invoking `runtime.StartTrace`, 2. and these gs will trigger `traceEvGoSysExit` events in `runtime.exitsyscall` when invoking go functions from c, 3. then, the events of those gs are under non-consistent ordering, due to missing the previous events. Add two events, `traceEvGoCreate` and `traceEvGoInSyscall`, in `runtime.StartTrace`, will make the trace parser happy. Fixes #29707 Change-Id: I2fd9d1713cda22f0ddb36efe1ab351f88da10881 GitHub-Last-Rev: 7bbfddb81b70041250e3c59ce53bea44f7afd2c3 GitHub-Pull-Request: golang/go#54974 Reviewed-on: https://go-review.googlesource.com/c/go/+/429858 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: xie cui <523516579@qq.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Michael Pratt <mpratt@google.com>
2022-09-27runtime: add cgo guard for exit hooks testThan McIntosh
Add an additional guard to ensure that we don't try to run the "-race" variant of the exit hooks test when CGO is explicitly turned off via CGO_ENABLED=0 (this fixes a failure on the no-cgo builder caused by CL 354790). Change-Id: I9dc7fbd71962e9a098916da69d9119a753f27116 Reviewed-on: https://go-review.googlesource.com/c/go/+/434935 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-26runtime: add an exit hook facilityThan McIntosh
Add a new API (not public/exported) for registering a function with the runtime that should be called when program execution terminates, to be used in the new code coverage re-implementation. The API looks like func addExitHook(f func(), runOnNonZeroExit bool) The first argument is the function to be run, second argument controls whether the function is invoked even if there is a call to os.Exit with a non-zero status. Exit hooks are run in reverse order of registration, e.g. the first hook to be registered will be the last to run. Exit hook functions are not allowed to panic or to make calls to os.Exit. Updates #51430. Change-Id: I906f8c5184b7c1666f05a62cfc7833bf1a4300c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/354790 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2022-09-21runtime: treat SI_TKILL like SI_USER on LinuxIan Lance Taylor
On Linux a signal sent using tgkill will have si_code == SI_TKILL, not SI_USER. Treat the two cases the same. Add a Linux-specific test. Change the test to use the C pause function rather than sleeping for a second, as that achieves the same effect. This is a roll forward of CL 431255 which was rolled back in CL 431715. This new version skips flaky tests on more systems, and marks a new method nosplit. Change-Id: Ibf2d3e6fc43d63d0a71afa8fcca6a11fda03f291 Reviewed-on: https://go-review.googlesource.com/c/go/+/432136 Auto-Submit: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-19Revert "runtime: treat SI_TKILL like SI_USER on Linux"Cuong Manh Le
This reverts CL 431255. Reason for revert: breaks darwin-arm and linux-noopt builders. Change-Id: I29332b935cc1e35fa039af3d70465e496361fcc9 Reviewed-on: https://go-review.googlesource.com/c/go/+/431715 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2022-09-17runtime: treat SI_TKILL like SI_USER on LinuxIan Lance Taylor
On Linux a signal sent using tgkill will have si_code == SI_TKILL, not SI_USER. Treat the two cases the same. Add a Linux-specific test. Change the test to use the C pause function rather than sleeping for a second, as that achieves the same effect. Change-Id: I2a36646aecabcab9ec42ed9a048b07c2ff0a3987 Reviewed-on: https://go-review.googlesource.com/c/go/+/431255 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2022-08-31cmd/compile: add support for unsafe.{String,StringData,SliceData}cuiweixie
For #53003 Change-Id: I13a761daca8b433b271a1feb711c103d9820772d Reviewed-on: https://go-review.googlesource.com/c/go/+/423774 Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: hopehook <hopehook@golangcn.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-08-15Revert "runtime/trace: add missing events for the locked g in extra M."Cuong Manh Le
This reverts commit ea9c3fd42d94182ce6f87104b68a51ea92f1a571. Reason for revert: break linux/ricsv64, openbsd/arm, illumos/amd64 builders Change-Id: I98479a8f63e76eed89a0e8846acf2c73e8441377 Reviewed-on: https://go-review.googlesource.com/c/go/+/423437 Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-08-12runtime/trace: add missing events for the locked g in extra M.doujiang24
Extra Ms may lead to the "no consistent ordering of events possible" error when parsing trace file with cgo enabled, since: 1. The gs in the extra Ms may be in `_Gdead` status while starting trace by invoking `runtime.StartTrace`, 2. and these gs will trigger `traceEvGoSysExit` events in `runtime.exitsyscall` when invoking go functions from c, 3. then, the events of those gs are under non-consistent ordering, due to missing the previous events. Add two events, `traceEvGoCreate` and `traceEvGoInSyscall`, in `runtime.StartTrace`, will make the trace parser happy. Fixes #29707 Change-Id: I7cc4b80822d2c46591304a59c9da2c9fc470f1d0 GitHub-Last-Rev: 445de8eaf3fb54e12795ac31e26650f821c5efbc GitHub-Pull-Request: golang/go#53284 Reviewed-on: https://go-review.googlesource.com/c/go/+/411034 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2022-08-12runtime: run "gofmt -s -w"Cuong Manh Le
Change-Id: I7eb3de35d1f1f0237962735450b37d738966f30c Reviewed-on: https://go-review.googlesource.com/c/go/+/423254 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@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-07-30runtime: fix typoshopehook
Change-Id: I30c125be6cb321aa03ea827bd11c3169087e3d4c Reviewed-on: https://go-review.googlesource.com/c/go/+/420314 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
2022-06-08runtime: gofmtMichael Pratt
libfuzzerHookStrCmp is manually reformatted into a proper go doc list. We don't always format testdata, but these test programs are standard Go programs that can be formatted. Change-Id: I4dde398bca225ae8c72e787e4d43fd0ccfd0a90b Reviewed-on: https://go-review.googlesource.com/c/go/+/411114 Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2022-05-17runtime: deflake TestCgoPprofThreadCherry Mui
In TestCgoPprofThread, the (fake) cgo traceback function pretends all C CPU samples are in cpuHogThread. But if a profiling signal lands in C code but outside of that thread, e.g. before/when the thread is created, we will get a sample which looks like Go calls into cpuHogThread. This CL makes the cgo traceback function only return cpuHogThread PCs when a signal lands on that thread. May fix #52726. Change-Id: I21c40f974d1882508626faf3ac45e8347fec31c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/406934 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-05-03runtime/debug: export SetMemoryLimitMichael Anthony Knyszek
This change also adds an end-to-end test for SetMemoryLimit as a testprog. Fixes #48409. Change-Id: I102d64acf0f36a43ee17b7029e8dfdd1ee5f057d Reviewed-on: https://go-review.googlesource.com/c/go/+/397018 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> 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-04-05all: separate doc comment from //go: directivesRuss Cox
A future change to gofmt will rewrite // Doc comment. //go:foo to // Doc comment. // //go:foo Apply that change preemptively to all comments (not necessarily just doc comments). For #51082. Change-Id: Iffe0285418d1e79d34526af3520b415a12203ca9 Reviewed-on: https://go-review.googlesource.com/c/go/+/384260 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-03-31runtime: remove use of -mnop-fun-dllimport from cgotest win.goThan McIntosh
This flag is not supported by clang, so remove it from the cgo cflags when building for windows. It is clear that it was needed at some point in the past, but it doesn't appear to be needed at the moment, since all.bash passes on windows without it now. Updates #35006. Change-Id: Ib06c891f516654138e3363e06645cd187e46ce4e Reviewed-on: https://go-review.googlesource.com/c/go/+/383838 Trust: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Trust: Than McIntosh <thanm@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-03-18runtime: allow TestCtrlHandler to run in ConPTYNuno Cruces
Fixes #51602. Previous test would not run in a pseudo-console (ConPTY). New test avoids taskkill entirely by having the child request its own console window be closed. Verified that this runs locally (within a real console), over SSH (within a pseudo-console), and that it breaks if #41884 were reverted. Change-Id: If868b92ec36647e5d0e4107e29a2a6e048d35ced GitHub-Last-Rev: b1421e4bed2dc729c266928f002b39374d7e391a GitHub-Pull-Request: golang/go#51681 Reviewed-on: https://go-review.googlesource.com/c/go/+/392874 Reviewed-by: Bryan Mills <bcmills@google.com> Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Trust: Alex Brainman <alex.brainman@gmail.com>
2022-02-19testdata: fix typo in commenthopehook
Change-Id: If3d5884d9f3f32606c510af5597529b832a8f4a9 Reviewed-on: https://go-review.googlesource.com/c/go/+/386934 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Trust: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
2022-02-03runtime: regression test for issue 50936Michael Pratt
Add a regression test for issue 50936 which coerces the runtime into frequent execution of the cgocall dropg/execute curg assignment race by making many concurrent cgo calls eligible for P retake by sysmon. This results in no P during exitsyscall, at which point they will update curg and will crash if SIGPROF arrives in between updating mp.curg and mp.curg.m. This test is conceptually similar to the basic cgo callback test in aprof.go but with additional concurrency and a sleep in C. On my machine this test fails ~5% of the time prior to CL 382079. For #50936. Change-Id: I21b6c7f2594f9a615a64580ef70a88b692505678 Reviewed-on: https://go-review.googlesource.com/c/go/+/382244 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>
2022-01-24runtime: call fflush before exiting in C testAustin Clements
Very, very rarely TestVectoredHandlerDontCrashOnLibrary fails because the C subprocess exits with a 0 status code and no output. This appears to happen because C does not actually guarantee that stdout will be flushed on exit and somehow, very rarely, it is not flushed. Add explicit fflushes to fix this. This reduces the failure rate of TestVectoredHandlerDontCrashOnLibrary from 0.0013% to 0% in 250,000 iterations. Fixes #49959. Change-Id: I892cf49a165ac91134c5da37588a2ab11e1f3f8b Reviewed-on: https://go-review.googlesource.com/c/go/+/380494 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
2022-01-20runtime: remove -tags=threadprof in testsIan Lance Taylor
Use an enviroment variable rather than a build tag to control starting a busy loop thread when testprogcgo starts. This lets us skip another build that invokes the C compiler and linker, which should avoid timeouts running the runtime tests. Fixes #44422 Change-Id: I516668d71a373da311d844990236566ff63e6d72 Reviewed-on: https://go-review.googlesource.com/c/go/+/379294 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2021-12-21runtime: check the correct environment variable in TestCgoCallbackGCCherry Mui
The test checks RUNTIME_TESTING_SHORT, whereas the test runner actually set RUNTIME_TEST_SHORT. Check the correct one. Updates #32023. Change-Id: Ie8ab00e1f5b8c02112a9aa1ee0e56028185c8a44 Reviewed-on: https://go-review.googlesource.com/c/go/+/373614 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
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-08runtime: fix flake in TestCgoPprofThreadRhys Hiltner
If the test's main goroutine receives a SIGPROF while creating the C-owned thread for the test, that sample will appear in the resulting profile. The root end of that stack will show a set of Go functions. The leaf end will be the C functions returned by the SetCgoTraceback handler, which will confuse the test runner. Add a label to the main goroutine while it calls in to C, so all profile samples that triggered the SetCgoTraceback handler are either correct, or can easily be excluded from the test's analysis. (The labels will not apply to the resulting C-owned thread, which does not use goroutines.) Fixes #43174 Change-Id: Ica3100ca0f191dcf91b30b0084e8541c5a25689f Reviewed-on: https://go-review.googlesource.com/c/go/+/370135 Reviewed-by: Michael Pratt <mpratt@google.com> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Trust: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-12-07runtime: fix comments on the behavior of SetGCPercentMichael Anthony Knyszek
Fixes for #49680, #49695, #45867, and #49370 all assumed that SetGCPercent(-1) doesn't block until the GC's mark phase is done, but it actually does. The cause of 3 of those 4 failures comes from the fact that at the beginning of the sweep phase, the GC does try to preempt every P once, and this may run concurrently with test code. In the fourth case, the issue was likely that only *one* of the debug_test.go tests was missing a call to SetGCPercent(-1). Just to be safe, leave a TODO there for now to remove the extraneous runtime.GC calls, but leave the calls in. Updates #49680, #49695, #45867, and #49370. Change-Id: Ibf4e64addfba18312526968bcf40f1f5d54eb3f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/369815 Reviewed-by: Austin Clements <austin@google.com> Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-12-06runtime: call runtime.GC in several tests that disable GCMichael Anthony Knyszek
These tests disable GC because of the potential for a deadlock, but don't consider that a GC could be in progress due to other tests. The likelihood of this case was increased when the minimum heap size was lowered during the Go 1.18 cycle. The issue was then mitigated by CL 368137 but in theory is always a problem. This change is intended specifically for #45867, but I just walked over a whole bunch of other tests that don't take this precaution where it seems like it could be relevant (some tests it's not, like the UserForcedGC test, or testprogs where no other code has run before it). Fixes #45867. Change-Id: I6a1b4ae73e05cab5a0b2d2cce14126bd13be0ba5 Reviewed-on: https://go-review.googlesource.com/c/go/+/369747 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: David Chase <drchase@google.com> Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-11-22runtime: in TestSpuriousWakeupsNeverHangSemasleep, wait for the runtime to ↵Bryan C. Mills
register handlers According to https://man7.org/linux/man-pages/man7/signal.7.html, the default behavior of SIGIO is to terminate the program. The Go runtime changes that behavior with its own signal handler, so the program will terminate if we send the signal before the runtime has finished setting up. Fixes #49727 Change-Id: I65db66f5176831c8d7454eebc0138d825c68e100 Reviewed-on: https://go-review.googlesource.com/c/go/+/366255 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-11-12runtime: drop cgoTraceback call assumptions from CgoPprof testsMichael Pratt
the CgoPprof tests currently assume that calls to their cgoTraceback functions are primarily for generating pprof samples and exit early after receiving two calls. This is a fragile assumption, as cgoTraceback will be called for _any_ signal received, hence why the test already looks for 2 calls instead of 1. Still, this has caused flaky failures in two cases: * #37201, where async preemption signals add additional probability of receiving non-profiling signals. This was resolved by disabling async preemption. * #49401, where some ITIMER_PROF SIGPROF signals are ignored in favor of per-thread SIGPROF signals. Rather than attempting to keep plugging holes, this CL drops the fragile assumption from these tests. Now they simply unconditionally run for the full 1s before exiting. Fixes #49401 Change-Id: I16dc9d2f16c2fb511e9db93dd096a402121f86ac Reviewed-on: https://go-review.googlesource.com/c/go/+/363634 Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Rhys Hiltner <rhys@justin.tv>
2021-11-11runtime: adjust TestPhysicalMemoryUtilization to handle large page sizesMichael Anthony Knyszek
Currently TestPhysicalMemoryUtilization can fail on systems with large physical page sizes like 64 KiB because all the of the holes to be scavenged are not aligned to the page size. The holes themselves are 64 KiB so this is actually quite likely. Bump the size of the allocations for systems with larger physical page sizes, and add additional slack to the threshold for unaligned pieces of the holes that may be unaligned. Fixes #49411. Change-Id: Iafb35b8761dc9cdc53d3745c4771b1a64c5c97b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/363415 Trust: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com>
2021-11-11runtime: fix C compilation error in TestCgoTracebackGoroutineProfileCherry Mui
Use C89 declaration. Also fix indentation. Change-Id: Ib974eb32ac95610d0b0eca00ca3b139b388c73bd Reviewed-on: https://go-review.googlesource.com/c/go/+/363356 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 22:32:12 +0000