aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/testdata
AgeCommit message (Collapse)Author
2019-03-14[release-branch.go1.11] runtime: skip TestLockOSThreadAvoidsStatePropagation ↵Michael Anthony Knyszek
if one can't unshare This change splits a testprog out of TestLockOSThreadExit and makes it its own test. Then, this change makes the testprog exit prematurely with a special message if unshare fails with EPERM because not all of the builders allow the user to call the unshare syscall. Also, do some minor cleanup on the TestLockOSThread* tests. Fixes #29366. Change-Id: Id8a9f6c4b16e26af92ed2916b90b0249ba226dbe Reviewed-on: https://go-review.googlesource.com/c/155437 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 429bae715876c69853bb63db1733f580e293c916) Reviewed-on: https://go-review.googlesource.com/c/go/+/167707 Run-TryBot: Andrew Bonventre <andybons@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2018-12-19[release-branch.go1.11] runtime: don't clear lockedExt on locked M when G exitsMichael Anthony Knyszek
When a locked M has its G exit without calling UnlockOSThread, then lockedExt on it was getting cleared. Unfortunately, this meant that during P handoff, if a new M was started, it might get forked (on most OSes besides Windows) from the locked M, which could have kernel state attached to it. To solve this, just don't clear lockedExt. At the point where the locked M has its G exit, it will also exit in accordance with the LockOSThread API. So, we can safely assume that it's lockedExt state will no longer be used. For the case of the main thread where it just gets wedged instead of exiting, it's probably better for it to keep the locked marker since it more accurately represents its state. Fixed #28986. Change-Id: I7d3d71dd65bcb873e9758086d2cbcb9a06429b0f Reviewed-on: https://go-review.googlesource.com/c/155117 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2018-07-02runtime: query thread stack size from OS on WindowsAustin Clements
Currently, on Windows, the thread stack size is set or assumed in many different places. In non-cgo binaries, both the Go linker and the runtime have a copy of the stack size, the Go linker sets the size of the main thread stack, and the runtime sets the size of other thread stacks. In cgo binaries, the external linker sets the main thread stack size, the runtime assumes the size of the main thread stack will be the same as used by the Go linker, and the cgo entry code assumes the same. Furthermore, users can change the main thread stack size using editbin, so the runtime doesn't even really know what size it is, and user C code can create threads with unknown thread stack sizes, which we also assume have the same default stack size. This is all a mess. Fix the corner cases of this and the duplication of knowledge between the linker and the runtime by querying the OS for the stack bounds during thread setup. Furthermore, we unify all of this into just runtime.minit for both cgo and non-cgo binaries and for the main thread, other runtime-created threads, and C-created threads. Updates #20975. Change-Id: I45dbee2b5ea2ae721a85a27680737ff046f9d464 Reviewed-on: https://go-review.googlesource.com/120336 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-06-19runtime: fix FreeBSDNumCPU testDavid Carlier
num cpu unit test fixes for FreeBSD. cpuset -g can possibly output more data than expected. Fixes #25924 Change-Id: Iec45a919df68648759331da7cd1fa3b9f3ca4241 GitHub-Last-Rev: 4cc275b519cda13189ec48b581ab9ce00cacd7f6 GitHub-Pull-Request: golang/go#25931 Reviewed-on: https://go-review.googlesource.com/119376 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-04-13runtime/traceback: support tracking goroutine ancestor tracebacks with ↵Eric Daniels
GODEBUG="tracebackancestors=N" Currently, collecting a stack trace via runtime.Stack captures the stack for the immediately running goroutines. This change extends those tracebacks to include the tracebacks of their ancestors. This is done with a low memory cost and only utilized when debug option tracebackancestors is set to a value greater than 0. Resolves #22289 Change-Id: I7edacc62b2ee3bd278600c4a21052c351f313f3a Reviewed-on: https://go-review.googlesource.com/70993 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2018-03-27cmd/go, cmd/link, runtime: enable PIE build mode, cgo race tests on FreeBSDTim Wright
Fixes #24546 Change-Id: I99ebd5bc18e5c5e42eee4689644a7a8b02405f31 Reviewed-on: https://go-review.googlesource.com/102616 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
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-31runtime: fail silently if we unwind over sigpanic into C codeAustin Clements
If we're running C code and the code panics, the runtime will inject a call to sigpanic into the C code just like it would into Go code. However, the return PC from this sigpanic will be in C code. We used to silently abort the traceback if we didn't recognize a return PC, so this went by quietly. Now we're much louder because in general this is a bad thing. However, in this one particular case, it's fine, so if we're in cgo and are looking at the return PC of sigpanic, silence the debug output. Fixes #23576. Change-Id: I03d0c14d4e4d25b29b1f5804f5e9ccc4f742f876 Reviewed-on: https://go-review.googlesource.com/90896 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
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-12-09runtime: don't use MAP_STACK in SigStack testIan Lance Taylor
On DragonFly mmap with MAP_STACK returns the top of the region, not the bottom. Rather than try to cope, just don't use the flag anywhere. Fixes #23061 Change-Id: Ib5df4dd7c934b3efecfc4bc87f8989b4c37555d7 Reviewed-on: https://go-review.googlesource.com/83035 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-12-01runtime: use MAP_ANON in sigstack checkAustin Clements
MAP_ANON is the deprecated but more portable spelling of MAP_ANONYMOUS. Use MAP_ANON to un-break the Darwin 10.10 builder. Updates #22930. Change-Id: Iedd6232b94390b3b2a7423c45cdcb25c1a5b3323 Reviewed-on: https://go-review.googlesource.com/81615 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-12-01runtime: restore the Go-allocated signal stack in unminitAustin Clements
Currently, when we minit on a thread that already has an alternate signal stack (e.g., because the M was an extram being used for a cgo callback, or to handle a signal on a C thread, or because the platform's libc always allocates a signal stack like on Android), we simply drop the Go-allocated gsignal stack on the floor. This is a problem for Ms on the extram list because those Ms may later be reused for a different thread that may not have its own alternate signal stack. On tip, this manifests as a crash in sigaltstack because we clear the gsignal stack bounds in unminit and later try to use those cleared bounds when we re-minit that M. On 1.9 and earlier, we didn't clear the bounds, so this manifests as running more than one signal handler on the same signal stack, which could lead to arbitrary memory corruption. This CL fixes this problem by saving the Go-allocated gsignal stack in a new field in the m struct when overwriting it with a system-provided signal stack, and then restoring the original gsignal stack in unminit. This CL is designed to be easy to back-port to 1.9. It won't quite cherry-pick cleanly, but it should be sufficient to simply ignore the change in mexit (which didn't exist in 1.9). Now that we always have a place to stash the original signal stack in the m struct, there are some simplifications we can make to the signal stack handling. We'll do those in a later CL. Fixes #22930. Change-Id: I55c5a6dd9d97532f131146afdef0b216e1433054 Reviewed-on: https://go-review.googlesource.com/81476 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2017-11-03cmd/link: restore windows stack commit size back to 4KBAlex Brainman
CL 49331 increased windows stack commit size to 2MB by mistake. Revert that change. Fixes #22439 Change-Id: I919e549e87da326f4ba45890b4d32f6d7046186f Reviewed-on: https://go-review.googlesource.com/74490 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
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-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-08-29runtime: forward crashing signals to late handlersElias Naur
CL 49590 made it possible for external signal handlers to catch signals from a crashing Go process. This CL extends that support to handlers registered after the Go runtime has initialized. Updates #20392 (and possibly fix it). Change-Id: I18eccd5e958a505f4d1782a7fc51c16bd3a4ff9c Reviewed-on: https://go-review.googlesource.com/57291 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2017-08-10runtime: when dying from a signal use the previous signal handlerElias Naur
Before this CL, whenever the Go runtime wanted to kill its own process with a signal dieFromSignal would reset the signal handler to _SIG_DFL. Unfortunately, if any signal handler were installed before the Go runtime initialized, it wouldn't be invoked either. Instead, use whatever signal handler was installed before initialization. The motivating use case is Crashlytics on Android. Before this CL, Crashlytics would not consider a crash from a panic() since the corresponding SIGABRT never reached its signal handler. Updates #11382 Updates #20392 (perhaps even fixes it) Fixes #19389 Change-Id: I0c8633329433b45cbb3b16571bea227e38e8be2e Reviewed-on: https://go-review.googlesource.com/49590 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2017-06-27runtime: get more info for TestCgoSignalDeadlock failuresIan Lance Taylor
Updates #18598 Change-Id: I13c60124714cf9d1537efa0a7dd1e6a0fed9ae5b Reviewed-on: https://go-review.googlesource.com/46723 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-06-14runtime: don't run TestCgoNumGoroutine on Windows or Plan 9Ian Lance Taylor
The test requires pthreads. Fixes #20666. Change-Id: Icb2400250a80cdad6680cd1ef6c18ef7343d5e29 Reviewed-on: https://go-review.googlesource.com/45701 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-06-14runtime, syscall: reset signal handlers to default in childIan Lance Taylor
Block all signals during a fork. In the parent process, after the fork, restore the signal mask. In the child process, reset all currently handled signals to the default handler, and then restore the signal mask. The effect of this is that the child will be operating using the same signal regime as the program it is about to exec, as exec resets all non-ignored signals to the default, and preserves the signal mask. We do this so that in the case of a signal sent to the process group, the child process will not try to run a signal handler while in the precarious state after a fork. Fixes #18600. Change-Id: I9f39aaa3884035908d687ee323c975f349d5faaa Reviewed-on: https://go-review.googlesource.com/45471 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-06-07runtime: mark extra M's G as dead when not in useAustin Clements
Currently the extra Ms created for cgo callbacks have a corresponding G that's kept in syscall state with only a call to goexit on its stack. This leads to confusing output from runtime.NumGoroutines and in tracebacks: goroutine 17 [syscall, locked to thread]: runtime.goexit() .../src/runtime/asm_amd64.s:2197 +0x1 Fix this by putting this goroutine into state _Gdead when it's not in use instead of _Gsyscall. To keep the goroutine counts correct, we also add one to sched.ngsys while the goroutine is in _Gdead. The effect of this is as if the goroutine simply doesn't exist when it's not in use. Fixes #16631. Fixes #16714. Change-Id: Ieae08a2febd4b3d00bef5c23fd6ca88fb2bb0087 Reviewed-on: https://go-review.googlesource.com/45030 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@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>
2017-03-10runtime: use cpuset_getaffinity for runtime.NumCPU() on FreeBSDDavid NewHamlet
In FreeBSD when run Go proc under a given sub-list of processors(e.g. 'cpuset -l 0 ./a.out' in multi-core system), runtime.NumCPU() still return all physical CPUs from sysctl hw.ncpu instead of account from sub-list. Fix by use syscall cpuset_getaffinity to account the number of sub-list. Fixes #15206 Change-Id: If87c4b620e870486efa100685db5debbf1210a5b Reviewed-on: https://go-review.googlesource.com/29341 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
2017-01-30runtime: add explicit (void) in C to avoid GCC 7 problemIan Lance Taylor
This avoids errors like ./traceback.go:80:2: call of non-function C.f1 I filed https://gcc.gnu.org/PR79289 for the GCC problem. I think this is a bug in GCC, and it may be fixed before the final GCC 7 release. This CL is correct either way. Fixes #18855. Change-Id: I0785a7b7c5b1d0ca87b454b5eca9079f390fcbd4 Reviewed-on: https://go-review.googlesource.com/35919 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-11-04all: make copyright headers consistent with one space after periodMichael Munday
Continuation of CL 20111. Change-Id: Ie2f62237e6ec316989c021de9b267cc9d6ee6676 Reviewed-on: https://go-review.googlesource.com/32830 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-11-03runtime/testdata/testprog: increase GCFairness2 timeout to 1sQuentin Smith
OpenBSD's scheduler causes preemption to take 20+ms, so 30ms is not enough time for 3 goroutines to run. This change continues to sleep for 30ms, but if it finds that the 3 goroutines have not run, it sleeps for an additional 1s before declaring failure. Updates #17712 Change-Id: I3e886e40d05192b7cb71b4f242af195836ef62a8 Reviewed-on: https://go-review.googlesource.com/32634 Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Quentin Smith <quentin@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-10-11runtime: record current PC for SIGPROF on non-Go threadIan Lance Taylor
If we get a SIGPROF on a non-Go thread, and the program has not called runtime.SetCgoTraceback so we have no way to collect a stack trace, then record a profile that is just the PC where the signal occurred. That will at least point the user to the right area. Retrieving the PC from the sigctxt in a signal handler on a non-G thread required marking a number of trivial sigctxt methods as nosplit, and, for extra safety, nowritebarrierrec. The test shows that the existing test CgoPprofThread test does not test the stack trace, just the profile signal. Leaving that for later. Change-Id: I8f8f3ff09ac099fc9d9df94b5a9d210ffc20c4ab Reviewed-on: https://go-review.googlesource.com/30252 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2016-10-06runtime: add threadprof tag for test that starts busy threadIan Lance Taylor
The CgoExternalThreadSIGPROF test starts a thread at constructor time that does a busy loop. That can throw off some other tests. So only build that code if testprogcgo is built with the tag threadprof, and adjust the tests that use that code to pass that build tag. This revealed that the CgoPprofThread test was not testing what it should have, as it never actually started the cpuHog thread. It was passing because of the busy loop thread. Fix it to start the thread as intended. Change-Id: I087a9e4fc734a86be16a287456441afac5676beb Reviewed-on: https://go-review.googlesource.com/30362 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-05runtime/testdata/testprogcgo: add explicit return value to signalThreadMichael Munday
Should fix the clang builder. Change-Id: I3ee34581b6a7ec902420de72a8a08a2426997782 Reviewed-on: https://go-review.googlesource.com/30363 Run-TryBot: Michael Munday <munday@ca.ibm.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-10-05runtime: don't call cgocallback from signal handlerIan Lance Taylor
Calling cgocallback from a signal handler can fail when using the race detector. Calling cgocallback will lead to a call to newextram which will call oneNewExtraM which will call racegostart. The racegostart function will set up some race detector data structures, and doing that will sometimes call the C memory allocator. If we are running the signal handler from a signal that interrupted the C memory allocator, we will crash or hang. Instead, change the signal handler code to call needm and dropm. The needm function will grab allocated m and g structures and initialize the g to use the current stack--the signal stack. That is all we need to safely call code that allocates memory and checks whether it needs to split the stack. This may temporarily leave us with no m available to run a cgo callback, but that is OK in this case since the code we call will quickly either crash or call dropm to return the m. Implementing this required changing some of the setSignalstackSP functions to avoid a write barrier. These functions never need a write barrier but in some cases generated one anyhow because on some systems the ss_sp field is a pointer. Change-Id: I3893f47c3a66278f85eab7f94c1ab11d4f3be133 Reviewed-on: https://go-review.googlesource.com/30218 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2016-10-05runtime: avoid endless loop if printing the panic value panicsIan Lance Taylor
Change-Id: I56de359a5ccdc0a10925cd372fa86534353c6ca0 Reviewed-on: https://go-review.googlesource.com/30358 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-09-23runtime: use sched_yield instead of pthread_yieldDavid Crawshaw
Attempt to fix the linux-amd64-clang builder, which broke with CL 29472. Turns out pthread_yield is a non-portable Linux function, and should have #define _GNU_SOURCE before #include <pthread.h>. GCC doesn't complain about this, but Clang does: ./raceprof.go:44:3: warning: implicit declaration of function 'pthread_yield' is invalid in C99 [-Wimplicit-function-declaration] (Though the error, while explicable, certainly could be clearer.) There is a portable POSIX equivalent, sched_yield, so this CL uses it instead. Change-Id: I58ca7a3f73a2b3697712fdb02e72a8027c391169 Reviewed-on: https://go-review.googlesource.com/29675 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-09-22cmd/compile: don't instrument copy and append in runtimeIan Lance Taylor
Instrumenting copy and append for the race detector changes them to call different functions. In the runtime package the alternate functions are not marked as nosplit. This caused a crash in the SIGPROF handler when invoked on a non-Go thread in a program built with the race detector. In some cases the handler can call copy, the race detector changed that to a call to a non-nosplit function, the function tried to check the stack guard, and crashed because it was running on a non-Go thread. The SIGPROF handler is written carefully to avoid such problems, but hidden function calls are difficult to avoid. Fix this by changing the compiler to not instrument copy and append when compiling the runtime package. Change the runtime package to add explicit race checks for the only code I could find where copy is used to write to user data (append is never used). Change-Id: I11078a66c0aaa459a7d2b827b49f4147922050af Reviewed-on: https://go-review.googlesource.com/29472 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2016-08-23runtime: remove unused function in testIan Lance Taylor
Change-Id: I43f14cdd9eb4a1d5471fc88c1b4759ceb2c674cf Reviewed-on: https://go-review.googlesource.com/24817 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-08-16runtime: fix map iterator concurrent map checkKeith Randall
We should check whether there is a concurrent writer at the start of every mapiternext, not just in mapaccessK (which is only called during certain map growth situations). Tests turned off by default because they are inherently flaky. Fixes #16278 Change-Id: I8b72cab1b8c59d1923bec6fa3eabc932e4e91542 Reviewed-on: https://go-review.googlesource.com/24749 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2016-08-16runtime: move printing of extra newlineJosh Bleecher Snyder
No functional changes, makes vet happy. Updates #11041 Change-Id: I59f3aba46d19b86d605508978652d76a1fe7ac7b Reviewed-on: https://go-review.googlesource.com/27125 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-06-21cmd/pprof: don't use offset if we don't have a start addressIan Lance Taylor
The test is in the runtime package because there are other tests of pprof there. At some point we should probably move them all into a pprof testsuite. Fixes #16128. Change-Id: Ieefa40c61cf3edde11fe0cf04da1debfd8b3d7c0 Reviewed-on: https://go-review.googlesource.com/24274 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
2016-06-16runtime: remove useless loop from CgoCCodeSIGPROF test programIan Lance Taylor
I verified that the test fails if I undo the change that it tests for. Updates #14732. Change-Id: Ib30352580236adefae946450ddd6cd65a62b7cdf Reviewed-on: https://go-review.googlesource.com/24151 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
2016-06-13runtime: collect stack trace if SIGPROF arrives on non-Go threadIan Lance Taylor
Fixes #15994. Change-Id: I5aca91ab53985ac7dcb07ce094ec15eb8ec341f8 Reviewed-on: https://go-review.googlesource.com/23891 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-05-31runtime: pass signal context to cgo traceback functionIan Lance Taylor
When doing a backtrace from a signal that occurs in C code compiled without using -fasynchronous-unwind-tables, we have to rely on frame pointers. In order to do that, the traceback function needs the signal context to reliably pick up the frame pointer. Change-Id: I7b45930fced01685c337d108e0f146057928f876 Reviewed-on: https://go-review.googlesource.com/23494 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-05-19runtime: fix goroutine priority elevationAustin Clements
Currently it's possible for user code to exploit the high scheduler priority of the GC worker in conjunction with the runnext optimization to elevate a user goroutine to high priority so it will always run even if there are other runnable goroutines. For example, if a goroutine is in a tight allocation loop, the following can happen: 1. Goroutine 1 allocates, triggering a GC. 2. G 1 attempts an assist, but fails and blocks. 3. The scheduler runs the GC worker, since it is high priority. Note that this also starts a new scheduler quantum. 4. The GC worker does enough work to satisfy the assist. 5. The GC worker readies G 1, putting it in runnext. 6. GC finishes and the scheduler runs G 1 from runnext, giving it the rest of the GC worker's quantum. 7. Go to 1. Even if there are other goroutines on the run queue, they never get a chance to run in the above sequence. This requires a confluence of circumstances that make it unlikely, though not impossible, that it would happen in "real" code. In the test added by this commit, we force this confluence by setting GOMAXPROCS to 1 and GOGC to 1 so it's easy for the test to repeated trigger GC and wake from a blocked assist. We fix this by making GC always put user goroutines at the end of the run queue, instead of in runnext. This makes it so user code can't piggy-back on the GC's high priority to make a user goroutine act like it has high priority. The only other situation where GC wakes user goroutines is waking all blocked assists at the end, but this uses the global run queue and hence doesn't have this problem. Fixes #15706. Change-Id: I1589dee4b7b7d0c9c8575ed3472226084dfce8bc Reviewed-on: https://go-review.googlesource.com/23172 Reviewed-by: Rick Hudson <rlh@golang.org>
2016-05-18runtime: deflake TestSignalExitStatusIan Lance Taylor
The signal might get delivered to a different thread, and that thread might not run again before the currently running thread returns and exits. Sleep to give the other thread time to pick up the signal and crash. Not tested for all cases, but, optimistically: Fixes #14063. Change-Id: Iff58669ac6185ad91cce85e0e86f17497a3659fd Reviewed-on: https://go-review.googlesource.com/23203 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
2016-05-10runtime/testdata/testprogcgo: fix Windows C compiler warningBrad Fitzpatrick
Noticed and fix by Alex Brainman. Tested in https://golang.org/cl/23005 (which makes all compiler warnings fatal during development) Fixes #15623 Change-Id: Ic19999fce8bb8640d963965cc328574efadd7855 Reviewed-on: https://go-review.googlesource.com/23010 Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
2016-05-05runtime: put tracebackctxt C functions in .c fileIan Lance Taylor
Since tracebackctxt.go uses //export functions, the C functions can't be externally visible in the C comment. The code was using attributes to work around that, but that failed on Windows. Change-Id: If4449fd8209a8998b4f6855ea89e5db1471b2981 Reviewed-on: https://go-review.googlesource.com/22786 Reviewed-by: Minux Ma <minux@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-05-04runtime: use cgo traceback for SIGPROFIan Lance Taylor
If we collected a cgo traceback when entering the SIGPROF signal handler, record it as part of the profiling stack trace. This serves as the promised test for https://golang.org/cl/21055 . Change-Id: I5f60cd6cea1d9b7c3932211483a6bfab60ed21d2 Reviewed-on: https://go-review.googlesource.com/22650 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2016-05-02all: make copyright headers consistent with one space after periodEmmanuel Odeke
Follows suit with https://go-review.googlesource.com/#/c/20111. Generated by running $ grep -R 'Go Authors. All' * | cut -d":" -f1 | while read F;do perl -pi -e 's/Go Authors. All/Go Authors. All/g' $F;done The code in cmd/internal/unvendor wasn't changed. Fixes #15213 Change-Id: I4f235cee0a62ec435f9e8540a1ec08ae03b1a75f Reviewed-on: https://go-review.googlesource.com/21819 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-04-29cmd/cgo, runtime, runtime/cgo: use cgo context functionIan Lance Taylor
Add support for the context function set by runtime.SetCgoTraceback. The context function was added in CL 17761, without support. This CL is the support. This CL has not been tested for real C code, as a working context function for C code requires unwind support that does not seem to exist. I wanted to get the CL out before the freeze. I apologize for the length of this CL. It's mostly plumbing, but unfortunately the plumbing is processor-specific. Change-Id: I8ce11a0de9b3dafcc29efd2649d776e93bff0e90 Reviewed-on: https://go-review.googlesource.com/22508 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-04-04cmd/go: fix -buildmode=c-archive should work on windowsChristopher Nelson
Add supporting code for runtime initialization, including both 32- and 64-bit x86 architectures. Add .ctors section on Windows to PE .o files, and INITENTRY to .ctors section to plug in to the GCC C/C++ startup initialization mechanism. This allows the Go runtime to initialize itself. Add .text section symbol for .ctor relocations. Note: This is unlikely to be useful for MSVC-based toolchains. Fixes #13494 Change-Id: I4286a96f70e5f5228acae88eef46e2bed95813f3 Reviewed-on: https://go-review.googlesource.com/18057 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
2016-04-01runtime: support symbolic backtrace of C code in a cgo crashIan Lance Taylor
The new function runtime.SetCgoTraceback may be used to register stack traceback and symbolizer functions, written in C, to do a stack traceback from cgo code. There is a sample implementation of runtime.SetCgoSymbolizer at github.com/ianlancetaylor/cgosymbolizer. Just importing that package is sufficient to get symbolic C backtraces. Currently only supported on linux/amd64. Change-Id: If96ee2eb41c6c7379d407b9561b87557bfe47341 Reviewed-on: https://go-review.googlesource.com/17761 Reviewed-by: Austin Clements <austin@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 17:31:10 +0000