aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/testdata
AgeCommit message (Collapse)Author
2019-09-25runtime: gofmt after CL 192937Tobias Klauser
CL 192937 introduced some changes which weren't properly gofmt'ed. Do so now. Change-Id: I2d2d57ea8a79fb41bc4ca59fa23f12198d615fd8 Reviewed-on: https://go-review.googlesource.com/c/go/+/196812 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-09-11runtime: fix crash during VDSO calls on armYuichi Nishiwaki
As discussed in #32912, a crash occurs when go runtime calls a VDSO function (say __vdso_clock_gettime) and a signal arrives to that thread. Since VDSO functions temporarily destroy the G register (R10), Go functions asynchronously executed in that thread (i.e. Go's signal handler) can try to load data from the destroyed G, which causes segmentation fault. To fix the issue a guard is inserted in front of sigtrampgo, so that the control escapes from signal handlers without touching G in case the signal occurred in the VDSO context. The test case included in the patch is take from discussion in a relevant thread on github: https://github.com/golang/go/issues/32912#issuecomment-517874531. This patch not only fixes the issue on AArch64 but also that on 32bit ARM. Fixes #32912 Change-Id: I657472e54b7aa3c617fabc5019ce63aa4105624a GitHub-Last-Rev: 28ce42c4a02a060f08c1b0dd1c9a392123fd2ee9 GitHub-Pull-Request: golang/go#34030 Reviewed-on: https://go-review.googlesource.com/c/go/+/192937 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-09-04runtime: platform-independent faketime supportAustin Clements
This adds a platform-independent implementation of nacl's faketime support. It can be enabled by setting the faketime build tag. Updates #30439. Change-Id: Iee097004d56d796e6d2bfdd303a092c067ade87e Reviewed-on: https://go-review.googlesource.com/c/go/+/192740 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-08-31runtime: do not crash in lastcontinuehandler when running as DLLSimon Ferquel
If Go DLL is used by external C program, and lastcontinuehandler is reached, lastcontinuehandler will crash the process it is running in. But it should not be up to Go runtime to decide if process to be crashed or not - it should be up to C runtime. This CL adjusts lastcontinuehandler to not to crash when running as DLL. Fixes #32648. Change-Id: Ia455e69b8dde2a6f42f06b90e8af4aa322ca269a GitHub-Last-Rev: dbdffcb43206e94ef130ecadd1c82a8763225ac2 GitHub-Pull-Request: golang/go#32574 Reviewed-on: https://go-review.googlesource.com/c/go/+/181839 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
2019-05-22all: shorten some testsRuss Cox
Shorten some of the longest tests that run during all.bash. Removes 7r 50u 21s from all.bash. After this change, all.bash is under 5 minutes again on my laptop. For #26473. Change-Id: Ie0460aa935808d65460408feaed210fbaa1d5d79 Reviewed-on: https://go-review.googlesource.com/c/go/+/177559 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-05-20runtime: overhaul TestPhysicalMemoryUtilizationMichael Anthony Knyszek
Currently, this test allocates many objects and relies on heap-growth scavenging to happen unconditionally on heap-growth. However with the new pacing system for the scavenging, this is no longer true and the test is flaky. So, this change overhauls TestPhysicalMemoryUtilization to check the same aspect of the runtime, but in a much more robust way. Firstly, it sets up a much more constrained scenario: only 5 objects are allocated total with a maximum worst-case (i.e. the test fails) memory footprint of about 16 MiB. The test is now aware that scavenging will only happen if the heap growth causes us to push way past our scavenge goal, which is based on the heap goal. So, it makes the holes in the test much bigger and the actual retained allocations much smaller to keep the heap goal at the heap's minimum size. It does this twice to create exactly two unscavenged holes. Because the ratio between the size of the "saved" objects and the "condemned" object is so small, two holes are sufficient to create a consistent test. Then, the test allocates one enormous object (the size of the 4 other objects allocated, combined) with the intent that heap-growth scavenging should kick in and scavenge the holes. The heap goal will rise after this object is allocated, so it's very important we do all the scavenging in a single allocation that exceeds the heap goal because otherwise the rising heap goal could foil our test. Finally, we check memory use relative to HeapAlloc as before. Since the runtime should scavenge the entirety of the remaining holes, theoretically there should be no more free and unscavenged memory. However due to other allocations that may happen during the test we may still see unscavenged memory, so we need to have some threshold. We keep the current 10% threshold which, while arbitrary, is very conservative and should easily account for any other allocations the test makes. Before, we also had to ensure the allocations we were making looked large relative to the size of a heap arena since newly-mapped memory was considered unscavenged, and so that could significantly skew the test. However, thanks to the fix for #32012 we were able to reduce memory use to 16 MiB in the worst case. Fixes #32010. Change-Id: Ia38130481e292f581da7fa3289c98c99dc5394ed Reviewed-on: https://go-review.googlesource.com/c/go/+/177237 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-03-19runtime: fix TestSigStackSwapping on aix/ppc64Clément Chigot
This commit fixes TestSigStackSwapping by increasing the signal stack size. This is needed because SIGSTKSZ is too small when VMX is used on AIX. Change-Id: Ic2b5faa65745228d0768383b3d6ebd4b6f9f532c Reviewed-on: https://go-review.googlesource.com/c/go/+/164012 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-03-06runtime: do not use a relative import in testdataBryan C. Mills
Relative imports do not work in module mode. Use a fully-qualified import path instead. Updates #30228 Change-Id: I0a42ffa521a7b513395e7e1788022d24cbb1f31a Reviewed-on: https://go-review.googlesource.com/c/go/+/165817 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-03-01runtime: scan defer closure in stack scanCherry Zhang
With stack objects, when we scan the stack, it scans defers with tracebackdefers, but it seems to me that tracebackdefers doesn't include the func value itself, which could be a stack allocated closure. Scan it explicitly. Alternatively, we can change tracebackdefers to include the func value, which in turn needs to change the type of stkframe. Fixes #30453. Change-Id: I55a6e43264d6952ab2fa5c638bebb89fdc410e2b Reviewed-on: https://go-review.googlesource.com/c/164118 Reviewed-by: Keith Randall <khr@golang.org>
2019-02-13runtime: scan gp._panic in stack scanCherry Zhang
In runtime.gopanic, the _panic object p is stack allocated and referenced from gp._panic. With stack objects, p on stack is dead at the point preprintpanics runs. gp._panic points to p, but stack scan doesn't look at gp. Heap scan of gp does look at gp._panic, but it stops and ignores the pointer as it points to the stack. So whatever p points to may be collected and clobbered. We need to scan gp._panic explicitly during stack scan. To test it reliably, we introduce a GODEBUG mode "clobberfree", which clobbers the memory content when the GC frees an object. Fixes #30150. Change-Id: I11128298f03a89f817faa221421a9d332b41dced Reviewed-on: https://go-review.googlesource.com/c/161778 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2019-01-18runtime: sample large heap allocations correctlyRaul Silvera
Remove an unnecessary check on the heap sampling code that forced sampling of all heap allocations larger than the sampling rate. This need to follow a poisson process so that they can be correctly unsampled. Maintain a check for MemProfileRate==1 to provide a mechanism for full sampling, as documented in https://golang.org/pkg/runtime/#pkg-variables. Additional testing for this change is on cl/129117. Fixes #26618 Change-Id: I7802bde2afc655cf42cffac34af9bafeb3361957 GitHub-Last-Rev: 471f747af845395d458096bea26daa93b91120be GitHub-Pull-Request: golang/go#29791 Reviewed-on: https://go-review.googlesource.com/c/158337 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2018-12-21runtime: skip TestLockOSThreadAvoidsStatePropagation if one can't unshareMichael Anthony Knyszek
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>
2018-12-19runtime: 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 OSs 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 #28979. Change-Id: I7d3d71dd65bcb873e9758086d2cbcb9a06429b0f Reviewed-on: https://go-review.googlesource.com/c/153078 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Austin Clements <austin@google.com>
2018-12-10runtime: fix CGO traceback frame countMark Pulford
Without this, each additional C frame found via SetCgoTraceback will cause a frame to be dropped from the bottom of the traceback stack. Fixes #29034 Change-Id: I90aa6b2a1dced90c69b64c5dd565fe64a25724a3 Reviewed-on: https://go-review.googlesource.com/c/151917 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-11-26cmd/compile: allow bodyless function if it is linkname'dKeith Randall
In assembly free packages (aka "complete" or "pure go"), allow bodyless functions if they are linkname'd to something else. Presumably the thing the function is linkname'd to has a definition. If not, the linker will complain. And linkname is unsafe, so we expect users to know what they are doing. Note this handles only one direction, where the linkname directive is in the local package. If the linkname directive is in the remote package, this CL won't help. (See os/signal/sig.s for an example.) Fixes #23311 Change-Id: I824361b4b582ee05976d94812e5b0e8b0f7a18a6 Reviewed-on: https://go-review.googlesource.com/c/151318 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-05runtime: deflake TestTracebackAncestorsAustin Clements
TestTracebackAncestors has a ~0.1% chance of failing with more goroutines in the traceback than expected. This happens because there's a window between each goroutine starting its child and that goroutine actually exiting. The test captures its own stack trace after everything is "done", but if this happens during that window, it will include the goroutine that's in the process of being torn down. Here's an example of such a failure: https://build.golang.org/log/fad10d0625295eb79fa879f53b8b32b9d0596af8 This CL fixes this by recording the goroutines that are expected to exit and removing them from the stack trace. With this fix, this test passed 15,000 times with no failures. Change-Id: I71e7c6282987a15e8b74188b9c585aa2ca97cbcd Reviewed-on: https://go-review.googlesource.com/c/147517 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-10-30runtime: add physical memory scavenging testMichael Anthony Knyszek
This change introduces a test to malloc_test which checks for overuse of physical memory in the large object treap. Due to fragmentation, there may be many pages of physical memory that are sitting unused in large-object space. For #14045. Change-Id: I3722468f45063b11246dde6301c7ad02ae34be55 Reviewed-on: https://go-review.googlesource.com/c/138918 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2018-09-18runtime: ignore EAGAIN from exec in TestCgoExecSignalMaskIan Lance Taylor
Fixes #27731 Change-Id: Ifb4d57923b1bba0210ec1f623d779d7b5f442812 Reviewed-on: https://go-review.googlesource.com/135995 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-08-22runtime: make TestGcSys actually test somethingIan Lance Taylor
The workthegc function was being inlined, and the slice did not escape, so there was no memory allocation. Use a sink variable to force memory allocation, at least for now. Fixes #23343 Change-Id: I02f4618e343c8b6cb552cb4e9f272e112785f7cf Reviewed-on: https://go-review.googlesource.com/122576 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 02:06:05 +0000