aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/testdata/testprog
AgeCommit message (Collapse)Author
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-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-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-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-08runtime: ensure abort actually crashes the processAustin Clements
On all non-x86 arches, runtime.abort simply reads from nil. Unfortunately, if this happens on a user stack, the signal handler will dutifully turn this into a panicmem, which lets user defers run and which user code can even recover from. To fix this, add an explicit check to the signal handler that turns faults in abort into hard crashes directly in the signal handler. This has the added benefit of giving a register dump at the abort point. Change-Id: If26a7f13790745ee3867db7f53b72d8281176d70 Reviewed-on: https://go-review.googlesource.com/93661 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-03-07runtime: get traceback from VDSO codeIan Lance Taylor
Currently if a profiling signal arrives while executing within a VDSO the profiler will report _ExternalCode, which is needlessly confusing for a pure Go program. Change the VDSO calling code to record the caller's PC/SP, so that we can do a traceback from that point. If that fails for some reason, report _VDSO rather than _ExternalCode, which should at least point in the right direction. This adds some instructions to the code that calls the VDSO, but the slowdown is reasonably negligible: name old time/op new time/op delta ClockVDSOAndFallbackPaths/vDSO-8 40.5ns ± 2% 41.3ns ± 1% +1.85% (p=0.002 n=10+10) ClockVDSOAndFallbackPaths/Fallback-8 41.9ns ± 1% 43.5ns ± 1% +3.84% (p=0.000 n=9+9) TimeNow-8 41.5ns ± 3% 41.5ns ± 2% ~ (p=0.723 n=10+10) Fixes #24142 Change-Id: Iacd935db3c4c782150b3809aaa675a71799b1c9c Reviewed-on: https://go-review.googlesource.com/97315 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2018-01-22runtime: print hexdump on traceback failureAustin Clements
Currently, if anything goes wrong when printing a traceback, we simply cut off the traceback without any further diagnostics. Unfortunately, right now, we have a few issues that are difficult to debug because the traceback simply cuts off (#21431, #23484). This is an attempt to improve the debuggability of traceback failure by printing a diagnostic message plus a hex dump around the failed traceback frame when something goes wrong. The failures look like: goroutine 5 [running]: runtime: unexpected return pc for main.badLR2 called from 0xbad stack: frame={sp:0xc42004dfa8, fp:0xc42004dfc8} stack=[0xc42004d800,0xc42004e000) 000000c42004dea8: 0000000000000001 0000000000000001 000000c42004deb8: 000000c42004ded8 000000c42004ded8 000000c42004dec8: 0000000000427eea <runtime.dopanic+74> 000000c42004ded8 000000c42004ded8: 000000000044df70 <runtime.dopanic.func1+0> 000000c420001080 000000c42004dee8: 0000000000427b21 <runtime.gopanic+961> 000000c42004df08 000000c42004def8: 000000c42004df98 0000000000427b21 <runtime.gopanic+961> 000000c42004df08: 0000000000000000 0000000000000000 000000c42004df18: 0000000000000000 0000000000000000 000000c42004df28: 0000000000000000 0000000000000000 000000c42004df38: 0000000000000000 000000c420001080 000000c42004df48: 0000000000000000 0000000000000000 000000c42004df58: 0000000000000000 0000000000000000 000000c42004df68: 000000c4200010a0 0000000000000000 000000c42004df78: 00000000004c6400 00000000005031d0 000000c42004df88: 0000000000000000 0000000000000000 000000c42004df98: 000000c42004dfb8 00000000004ae7d9 <main.badLR2+73> 000000c42004dfa8: <00000000004c6400 00000000005031d0 000000c42004dfb8: 000000c42004dfd0 !0000000000000bad 000000c42004dfc8: >0000000000000000 0000000000000000 000000c42004dfd8: 0000000000451821 <runtime.goexit+1> 0000000000000000 000000c42004dfe8: 0000000000000000 0000000000000000 000000c42004dff8: 0000000000000000 main.badLR2(0x0) /go/src/runtime/testdata/testprog/badtraceback.go:42 +0x49 For #21431, #23484. Change-Id: I8718fc76ced81adb0b4b0b4f2293f3219ca80786 Reviewed-on: https://go-review.googlesource.com/89016 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2017-11-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-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-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>
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-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-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-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-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-03-01all: make copyright headers consistent with one space after periodBrad Fitzpatrick
This is a subset of https://golang.org/cl/20022 with only the copyright header lines, so the next CL will be smaller and more reviewable. Go policy has been single space after periods in comments for some time. The copyright header template at: https://golang.org/doc/contribute.html#copyright also uses a single space. Make them all consistent. Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0 Reviewed-on: https://go-review.googlesource.com/20111 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-02-21runtime: when crash with panic, call user Error/String methods before ↵Shenghou Ma
freezing the world Fixes #14432. Change-Id: I0a92ef86de95de39217df9a664d8034ef685a906 Reviewed-on: https://go-review.googlesource.com/19792 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-02-16runtime: show panics in tracebackAustin Clements
We used to include panic calls in tracebacks; however, when runtime.panic was renamed to runtime.gopanic in the conversion of the runtime to Go, we missed the special case in showframe that includes panic calls even though they're in package runtime. Fix the function name check in showframe (and, while we're here, fix the other check for "runtime.panic" in runtime/pprof). Since the "runtime.gopanic" name doesn't match what users call panic and hence isn't very user-friendly, make traceback rewrite it to just "panic". Updates #5832, #13857. Fixes #14315. Change-Id: I8059621b41ec043e63d5cfb4cbee479f47f64973 Reviewed-on: https://go-review.googlesource.com/19492 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-13runtime: make NumGoroutine and Stack agree not to include system goroutinesRuss Cox
[Repeat of CL 18343 with build fixes.] Before, NumGoroutine counted system goroutines and Stack (usually) didn't show them, which was inconsistent and confusing. To resolve which way they should be consistent, it seems like package main import "runtime" func main() { println(runtime.NumGoroutine()) } should print 1 regardless of internal runtime details. Make it so. Fixes #11706. Change-Id: If26749fec06aa0ff84311f7941b88d140552e81d Reviewed-on: https://go-review.googlesource.com/18432 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Russ Cox <rsc@golang.org>
2016-01-08runtime/testdata: gofmtMikio Hara
Change-Id: I728d4c709c4122fe4b96e1350be73696ac6fb1f7 Reviewed-on: https://go-review.googlesource.com/18422 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-01-08Revert "runtime: make NumGoroutine and Stack agree not to include system ↵Russ Cox
goroutines" This reverts commit c5bafc828126c8fa057e1accaa448583c7ec145f. Change-Id: Ie7030c978c6263b9e996d5aa0e490086796df26d Reviewed-on: https://go-review.googlesource.com/18431 Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-08runtime: make NumGoroutine and Stack agree not to include system goroutinesRuss Cox
Before, NumGoroutine counted system goroutines and Stack (usually) didn't show them, which was inconsistent and confusing. To resolve which way they should be consistent, it seems like package main import "runtime" func main() { println(runtime.NumGoroutine()) } should print 1 regardless of internal runtime details. Make it so. Fixes #11706. Change-Id: I6bfe26a901de517728192cfb26a5568c4ef4fe47 Reviewed-on: https://go-review.googlesource.com/18343 Reviewed-by: Austin Clements <austin@google.com>
2016-01-05runtime: fix exit status when killed by signalIan Lance Taylor
Previously, when a program died because of a SIGHUP, SIGINT, or SIGTERM signal it would exit with status 2. This CL fixes the runtime to exit with a status indicating that the program was killed by a signal. Change-Id: Ic2982a2562857edfdccaf68856e0e4df532af136 Reviewed-on: https://go-review.googlesource.com/18156 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
2015-12-29runtime: move test programs out of source code, coalesceRuss Cox
Now there are just three programs to compile instead of many, and repeated tests can reuse the compilation result instead of rebuilding it. Combined, these changes reduce the time spent testing runtime during all.bash on my laptop from about 60 to about 30 seconds. (All.bash itself runs in 5½ minutes.) For #10571. Change-Id: Ie2c1798b847f1a635a860d11dcdab14375319ae9 Reviewed-on: https://go-review.googlesource.com/18085 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 02:25:40 +0000