- 15 Nov, 2019 16 commits
-
-
Ian Lance Taylor authored
The test is inherently slightly flaky, so repeat to reduce flakiness. Fixes #35537 Change-Id: Id918d48d33c7d5e19c4f24df104adc7fbf3720f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/207457 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
When we run tests, we may need to write the test binary (and/or test variants of its dependencies) to GOCACHE. (This also fixes several test cases in cmd/go, which preserves the GOCACHE variable for efficiency.) It is highly unlikely that tests will try to modify .git, and that directory contains many files, so don't bother with it. Updates #30316 Change-Id: Id11136c6c64d8f0afc6c6ba5d94c9269df231052 Reviewed-on: https://go-review.googlesource.com/c/go/+/207441 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ville Skyttä authored
Change-Id: I5b909df0fd048cd66c5a27fca1b06466d3bcaac7 GitHub-Last-Rev: 778c5d21311abee09a5fbda2e4005a5fd4cc3f9f GitHub-Pull-Request: golang/go#35624 Reviewed-on: https://go-review.googlesource.com/c/go/+/207421 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Elias Naur authored
CL 205340 changed the linker to skip certain flags when linking for iOS. However, for host linking on iOS (such as on the Corellium darwin/arm64 builders) the MachO platform defaults to PLATFORM_MACOS, and the flags are not skipped. Avoids warnings such as ld: warning: -no_pie ignored for arm64 Updates #32963 Change-Id: Ib6b4c2375fd14cf89410bf5ff1537b692b7a1c15 Reviewed-on: https://go-review.googlesource.com/c/go/+/206337 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Bryan C. Mills authored
While running various tests for #28387, I keep ending up with an unwritable GOROOT after a failure. While the unwritable GOROOT is a fairly exotic condition (normally only happens on builders), it's somewhat annoying when debugging, so I'm switching all of the log.Fatal* call sites to use the existing fatalf function, which supports general atexit-like cleanup. Updates #28387 Change-Id: I473cda7eacd9ad82bdeab647766373126dc7390e Reviewed-on: https://go-review.googlesource.com/c/go/+/207341 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan C. Mills authored
Updates #28387 Fixes #35619 Change-Id: I162f3427b7901c117e3f3e403df7edec7c529bd1 Reviewed-on: https://go-review.googlesource.com/c/go/+/207352 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan C. Mills authored
Previously, we were writing binaries to GOROOT without ever reading them. Updates #28387 Change-Id: Ic84999f46a367fcbf2ae1eac8bfdcbceb24dc748 Reviewed-on: https://go-review.googlesource.com/c/go/+/207342 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Agniva De Sarker authored
Updates #33848 Change-Id: I505490906be7cd6fbcdc6a05c1017c779dbf7bba Reviewed-on: https://go-review.googlesource.com/c/go/+/207397 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Bryan C. Mills authored
Fixes #34254 Change-Id: Ib4e476d31264342538c2cf381177823183cba890 Reviewed-on: https://go-review.googlesource.com/c/go/+/206761 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bryan C. Mills authored
Fixes #35617 Change-Id: I514f4e5f80ba9866c5cad3eb1fecd6f346c82f14 Reviewed-on: https://go-review.googlesource.com/c/go/+/207340 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael Anthony Knyszek authored
In scavengeOne's fast path, we currently don't check the summary for the chunk that scavAddr points to, which means that we might accidentally scavenge unused address space if the previous scavenge moves the scavAddr into that space. The result of this today is a crash. This change makes it so that scavengeOne's fast path only happens after the check, following the comment in mpagealloc.go. It also adds a test for this case. Fixes #35465. Updates #35112. Change-Id: I861d44ee75e42a0e1f5aaec243bc449228273903 Reviewed-on: https://go-review.googlesource.com/c/go/+/206978 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
go101 authored
Go specification says: A value x is assignable to a variable of type T if x is a bidirectional channel value, T is a channel type, x's type V and T have identical element types, and at least one of V or T is not a defined type. However, the current reflection implementation is incorrect which makes "x is assignable to T" even if type V and T are both defined type. The current reflection implementation also mistakes the base types of two non-defined pointer types share the same underlying type when the two base types satisfy the above mentioned special channel assignability rule. Fixes #29469 Change-Id: Ia4b9c4ac47dc8e76a11faef422b2e5c5726b78b3 GitHub-Last-Rev: 487c20a564091a1d2ba5feb95ab5196331c699c2 GitHub-Pull-Request: golang/go#29739 Reviewed-on: https://go-review.googlesource.com/c/go/+/157822 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Tobias Klauser authored
Like on other 64-bit GOARCHes, EpollEvent needs padding before Fd for mips64 and mips64le. Change-Id: I87773a1b305552ab4ed039623b40d2fff1f20d9b Reviewed-on: https://go-review.googlesource.com/c/go/+/207298 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Cherry Zhang authored
The 2-instruction TLS access sequence MOVQ TLS, BX MOVQ 0(BX)(TLS*1), BX is not async preemptible, as if it is preempted and resumed on a different thread, the TLS address may become invalid. May fix #35349. (This is a rare failure and I haven't been able to reproduce it.) Change-Id: Ie1a366fd0d7d73627dc62ee2de01c0aa09365f2b Reviewed-on: https://go-review.googlesource.com/c/go/+/206903 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com>
-
Cherry Zhang authored
When we receive a signal, if G is nil we call badsignal, which calls needm. When cgo is not used, there is no extra M, so needm will just hang. In this situation, even GOTRACEBACK=crash cannot get a stack trace, as we're in the signal handler and cannot receive another signal (SIGQUIT). Instead, just crash. For #35554. Updates #34391. Change-Id: I061ac43fc0ac480435c050083096d126b149d21f Reviewed-on: https://go-review.googlesource.com/c/go/+/206959 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Sergey Zagursky authored
The existing implementation is erroneously assume that having no deadline in context.Context means that time returned from Deadline method will have IsZero() == true. But technically speaking this is an invalid assumption. The context.Context interface specification doesn't specify what time should be returned from Deadline method when there is no deadline set. It only specifies that second result of Deadline should be false. Fixes #35594 Change-Id: Ife00aad77ab3585e469f15017550ac6c0431b140 Reviewed-on: https://go-review.googlesource.com/c/go/+/207297 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 14 Nov, 2019 6 commits
-
-
Jay Conrod authored
When -trimpath is used, packages built from the module cache still have debug into that contains the module path and version. Only the module cache directory is stripped. With this CL, we now include the module path and version in the cache key for build actions. Fixes #35412 Change-Id: I1956592d0d86fcea2cca7c5fc8957e83543d6aa2 Reviewed-on: https://go-review.googlesource.com/c/go/+/207317 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Bryan C. Mills authored
Updates #28387 Updates #30316 Fixes #35574 Change-Id: I21c9e18573909e092ed8dcec91b8542bb97e9f5a Reviewed-on: https://go-review.googlesource.com/c/go/+/207263Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Elias Naur authored
The NDK is switching to ldd, and will stop including the gold linker. Change-Id: If74168017c9874134b34010906ab1d94001528b6 Reviewed-on: https://go-review.googlesource.com/c/go/+/206840 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hana Kim authored
tryAdd shouldn't succeed (and accept the new frame) if the last existing frame on the deck is not an inlined frame. For example, when we see the followig stack [300656 300664 300655 300664] with each PC corresponds to [{PC:300656 Func:nil Function:runtime.nanotime File:/workdir/go/src/runtime/time_nofake.go Line:19 Entry:300416 {0x28dac8 0x386c80}}] [{PC:300664 Func:0x28dac8 Function:runtime.checkTimers File:/workdir/go/src/runtime/proc.go Line:2623 Entry:300416 {0x28dac8 0x386c80}}] [{PC:300655 Func:nil Function:runtime.nanotime File:/workdir/go/src/runtime/time_nofake.go Line:19 Entry:300416 {0x28dac8 0x386c80}}] [{PC:300664 Func:0x28dac8 Function:runtime.checkTimers File:/workdir/go/src/runtime/proc.go Line:2623 Entry:300416 {0x28dac8 0x386c80}}] PC:300656 and PC:300664 belong to a single location entry, but the bug in the current tryAdd logic placed the entire stack into one location entry. Also adds tests - this crash is a tricky case to test because I think it should happen with normal go code. The new TestTryAdd simulates it by using fake call sequences. The test crashed without the fix. Update #35538 Change-Id: I6d3483f757abf4c429ab91616e4def90832fc04a Reviewed-on: https://go-review.googlesource.com/c/go/+/206958Reviewed-by: Keith Randall <khr@golang.org>
-
Ian Lance Taylor authored
Fixes #35085 Change-Id: Ice611e1223392f687061a43fd4c2298ea22774fb Reviewed-on: https://go-review.googlesource.com/c/go/+/207081 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Yasuhiro Matsumoto authored
Fixes #35492 Change-Id: I00dce8fd1228f809e0c61013ac4de7a5953cbbf9 Reviewed-on: https://go-review.googlesource.com/c/go/+/206997 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 13 Nov, 2019 13 commits
-
-
Jay Conrod authored
'go build' now reports a more useful error when a relative path on the command line points to a directory that doesn't exist or a directory without .go files. Errors are generated by go/build.Context.ImportDir instead of a vague call to base.Fatalf in modload. Fixes #35414 Change-Id: I2642230c5e409107b98bb6d6c3a484d8d25b4147 Reviewed-on: https://go-review.googlesource.com/c/go/+/206902 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Ian Lance Taylor authored
It turns out that there is a path that initializes netpoll and opens file descriptors before running the os/exec init function: on some systems, the uses of NewFile when setting os.Stdin and friends can initialize netpoll which can open file descriptors. This in itself is not a problem, but when we check whether the new files are open using os.NewFile, a side-effect is to put them into non-blocking mode. This can then break future uses of netpoll. Updates #35469 Fixes #35566 Change-Id: I1b2e2c943695d1c2d29496b050abbce9ee710a00 Reviewed-on: https://go-review.googlesource.com/c/go/+/207078Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Bryan C. Mills authored
The bash version of the test wrote intermediate files to its testdata directory. Updates #28387 Updates #30316 Fixes #35536 Change-Id: Ib81b547d3c43e90df713a2172c8f399fefb53c68 Reviewed-on: https://go-review.googlesource.com/c/go/+/206901 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Rémy Oudompheng authored
The bounds in the last carry branch were wrong as there is no reason for len(u) >= n+n/2 to always hold true. We also adjust test to avoid using a remainder of 1 (in which case, the last step of the algorithm computes (qhatv+1) - qhatv which rarely produces a carry). Change-Id: I69fbab9c5e19d0db1c087fbfcd5b89352c2d26fb Reviewed-on: https://go-review.googlesource.com/c/go/+/206839 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Ian Lance Taylor authored
In the discussion of CL 171828 we decided that it was not necessary to acquire timersLock around the call to moveTimers, because the world is stopped. However, that is not correct, as sysmon runs even when the world is stopped, and it calls timeSleepUntil which looks through the timers. timeSleepUntil acquires timersLock, but that doesn't help if moveTimers is running at the same time. Updates #6239 Updates #27707 Updates #35462 Change-Id: I346c5bde594c4aff9955ae430b37c2b6fc71567f Reviewed-on: https://go-review.googlesource.com/c/go/+/206938 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
-
Cuong Manh Le authored
Change-Id: I09090effcc5d814d4e024da3f944e825365588f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/205477 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Than McIntosh authored
Test fix: in dwarf_test.go don't try to run the TestDWARF testpoint on windows with c-archive build mode (linker + debug/pe support for that build mode on Windows is not fully baked it seems). Fixes #35512. Change-Id: I1c87ff3d62e5b98e75062b184d762fb5ed937745 Reviewed-on: https://go-review.googlesource.com/c/go/+/206899 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Ian Lance Taylor authored
Our attempts to close existing open files are flaky. They will fail if, for example, file descriptor 3 is open when the test binary starts. Instead, report any such cases, and skip TestExtraFiles. Updates #35469 Change-Id: I7caec083f3f4a31579bf28fc9c82ae89b1bde49a Reviewed-on: https://go-review.googlesource.com/c/go/+/206939Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
ZYunH authored
change "fp" to "fd". Change-Id: I00e5fafcb68891356d508c49aa89969bfed7ed10 GitHub-Last-Rev: b06f976a3bacc6fc6f1fd0e4fc8c50da9764f736 GitHub-Pull-Request: golang/go#35557 Reviewed-on: https://go-review.googlesource.com/c/go/+/207038Reviewed-by: Keith Randall <khr@golang.org>
-
Bryan C. Mills authored
In CL 206757 I added a log.Printf to identify when GOROOT is not read-only. However, it interacts badly with test sharding in the builders: the log is repeated for every shard. Since the log statement isn't particularly high-value, just remove it. Updates #30316 Change-Id: I385a7f35da59e38ad8b9beef92dc11af931d9571 Reviewed-on: https://go-review.googlesource.com/c/go/+/206898 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Not a fix, but will give us more info when it flakes again. Updates #35113 Change-Id: I2f90c24530c1bea81dd9d8c7a59f4b0640dfa4c2 Reviewed-on: https://go-review.googlesource.com/c/go/+/206819 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Joel Sing authored
Provide initial linker support for riscv64. Based on riscv-go port. Updates #27532 Change-Id: I8a881ce41cd49efef0358bad9171d4d18aaf7ab2 Reviewed-on: https://go-review.googlesource.com/c/go/+/204624 Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Filippo Valsorda authored
Change-Id: Icd5006e37861d892a5f3d4397c3826179c1b12ad Reviewed-on: https://go-review.googlesource.com/c/go/+/206657 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
-
- 12 Nov, 2019 5 commits
-
-
Cherry Zhang authored
The problem should be fixed by the previous CL. Reenable async preemption on darwin/arm64. Updates #35439. Change-Id: I93e8c4702b4d8fe6abaa6fc9c27def5c8aed1b59 Reviewed-on: https://go-review.googlesource.com/c/go/+/206419Reviewed-by: Keith Randall <khr@golang.org>
-
Cherry Zhang authored
iOS does not support SA_ONSTACK. The signal handler runs on the G stack. Any writes below the SP may be clobbered by the signal handler (even without call injection). So we save LR after decrementing SP on iOS. Updates #35439. Change-Id: Ia6d7a0669e0bcf417b44c031d2e26675c1184165 Reviewed-on: https://go-review.googlesource.com/c/go/+/206418 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
David Chase authored
Change-Id: I9596536e04aef034623b51b42f44e4978f07ac47 Reviewed-on: https://go-review.googlesource.com/c/go/+/204339 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Carlo Alberto Ferraris authored
Some, but not all, architectures mix in OS-provided random seeds when initializing the fastrand state. The others have TODOs saying we need to do the same. Lift that logic up in the architecture-independent part, and use memhash to mix the seed instead of a simple addition. Previously, dumping the fastrand state at initialization would yield something like the following on linux-amd64, where the values in the first column do not change between runs (as thread IDs are sequential and always start at 0), and the values in the second column, while changing every run, are pretty correlated: first run: 0x0 0x44d82f1c 0x5f356495 0x44f339de 0xbe6ac92a 0x44f91cd8 0x1da02dbf 0x44fd91bc 0x7cd59254 0x44fee8a4 0xdc0af6e9 0x4547a1e0 0x3b405b7e 0x474c76fc 0x9a75c013 0x475309dc 0xf9ab24a8 0x4bffd075 second run: 0x0 0xa63fc3eb 0x5f356495 0xa6648dc2 0xbe6ac92a 0xa66c1c59 0x1da02dbf 0xa671bce8 0x7cd59254 0xa70e8287 0xdc0af6e9 0xa7129d2e 0x3b405b7e 0xa7379e2d 0x9a75c013 0xa7e4c64c 0xf9ab24a8 0xa7ecce07 With this change, we get initial states that appear to be much more unpredictable, both within the same run as well as between runs: 0x11bddad7 0x97241c63 0x553dacc6 0x2bcd8523 0x62c01085 0x16413d92 0x6f40e9e6 0x7a138de6 0xa4898053 0x70d816f0 0x5ca5b433 0x188a395b 0x62778ca9 0xd462c3b5 0xd6e160e4 0xac9b4bd 0xb9571d65 0x597a981d Change-Id: Ib22c530157d74200df0083f830e0408fd4aaea58 Reviewed-on: https://go-review.googlesource.com/c/go/+/203439 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Hana (Hyang-Ah) Kim authored
https://github.com/google/pprof/compare/54271f7e092f...27840fff0d09 Change-Id: I7ded9be6deaaf8d11bd8d228bca8d7eb3ada8774 Reviewed-on: https://go-review.googlesource.com/c/go/+/205780 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-