- 27 Nov, 2019 9 commits
-
-
Carlos Amedee authored
Adds an additional lock around an access to modOnly. Updates #35317 Change-Id: Ia1e75f9a674ec2a2c0489b41283c1cd3e7924d1e Reviewed-on: https://go-review.googlesource.com/c/go/+/209237 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Hana (Hyang-Ah) Kim authored
Lack of logging hinders debugging. Like many other go commands, let's allow users to inspect what is going on underneath. Example: $ GO111MODULE=on GOPROXY=direct GOPATH=`mktemp -d` go mod download -x golang.org/x/tools/gopls@latest mkdir -p /var/folders/bw/6r6k9d113sv1_vvzk_1kfxbm001py5/T/tmp.ykhTiXaS/pkg/mod/cache/vcs # git3 https://go.googlesource.com/tools ... Update #35849 Change-Id: I5577e683ae3c0145b11822df255b210ad9f60c87 Reviewed-on: https://go-review.googlesource.com/c/go/+/208558 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Jay Conrod authored
Updates #33637 Change-Id: I3b4303479b44894442a04226cbf1f1e27dbb2fb7 Reviewed-on: https://go-review.googlesource.com/c/go/+/208779Reviewed-by: Tyler Bui-Palsulich <tbp@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Michael Anthony Knyszek authored
Currently scavengeAll (which is called by debug.FreeOSMemory) doesn't reset the scavenge address before scavenging, meaning it could miss large portions of the heap. Fix this by reseting the address before scavenging, which will ensure it is able to walk over the entire heap. Fixes #35858. Change-Id: I4a7408050b8e134318ff94428f98cb96a1795aa9 Reviewed-on: https://go-review.googlesource.com/c/go/+/208960Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Updates bundled http2 to x/net git rev ef20fe5d7 for: http2: make Transport.IdleConnTimeout consider wall (not monotonic) time https://golang.org/cl/208798 (#29308) http2: make CipherSuites validation error more verbose https://golang.org/cl/200317 (#34776) http2: track unread bytes when the pipe is broken https://golang.org/cl/187377 (#28634) http2: split cookie pair into separate hpack header fields https://golang.org/cl/155657 (#29386) Fixes #29308 Fixes #28634 Change-Id: I71a03ca62ccb5ff35a5cfadd8dc705a4491ae7ea Reviewed-on: https://go-review.googlesource.com/c/go/+/209077Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mostyn Bramley-Moore authored
Note that ioutil.WriteFile's perm argument is the value before the umask is applied. Fixes #35835 Change-Id: I61cd9c88bced3be52b616d86e060cd3fd912ab1f Change-Id: I61cd9c88bced3be52b616d86e060cd3fd912ab1f GitHub-Last-Rev: 0069abb7c5d904fb11448148f44db023dbcf74aa GitHub-Pull-Request: golang/go#35836 Reviewed-on: https://go-review.googlesource.com/c/go/+/208838Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Cherry Zhang authored
Print the current SP and (old) stack bounds when the stack grows too large. This helps to identify the problem: whether a large stack is used, or something else goes wrong. For #35470. Change-Id: I34a4064d5c7280978391d835e171b90d06f87222 Reviewed-on: https://go-review.googlesource.com/c/go/+/207351Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
-
Cherry Zhang authored
When there are both a synchronous preemption request (by clobbering the stack guard) and an asynchronous one (by signal), the running goroutine may observe the synchronous request first in stack bounds check, and go to the path of calling morestack. If the preemption signal arrives at this point before the call to morestack, the goroutine will be asynchronously preempted, entering the scheduler. When it is resumed, the scheduler clears the preemption request, unclobbers the stack guard. But the resumed goroutine will still call morestack, as it is already on its way. morestack will, as there is no preemption request, double the stack unnecessarily. If this happens multiple times, the stack may grow too big, although only a small amount is actually used. To fix this, we mark the stack bounds check and the call to morestack async-nonpreemptible, starting after the memory instruction (mostly a load, on x86 CMP with memory). Not done for Wasm as it does not support async preemption. Fixes #35470. Change-Id: Ibd7f3d935a3649b80f47539116ec9b9556680cf2 Reviewed-on: https://go-review.googlesource.com/c/go/+/207350Reviewed-by: David Chase <drchase@google.com>
-
Cherry Zhang authored
Currently we use stack map index -2 to mark unsafe points, i.e. PC ranges that is not safe for async preemption. This has a problem: it cannot mark CALL instructions, because for stack scan a valid stack map index is needed. This CL switches to use register map index for marking unsafe points instead, which does not conflict with stack scan and can be applied on CALL instructions. This is necessary as next CL will mark call to morestack nonpreemptible. For #35470. Change-Id: I357bf26c996e1fee1e7eebe4e6bb07d62930d3f7 Reviewed-on: https://go-review.googlesource.com/c/go/+/207349Reviewed-by: David Chase <drchase@google.com>
-
- 26 Nov, 2019 4 commits
-
-
Jay Conrod authored
Based on 'go help goproxy'. Updates #33637 Change-Id: I2f3477cfc8f6fb53515604a28a5bc01eb4fe8f48 Reviewed-on: https://go-review.googlesource.com/c/go/+/208777Reviewed-by: Katie Hockman <katie@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Jay Conrod authored
This CL pulls in a fix to golang.org/x/mod/modfile. No change needed to cmd/go. Fixes #35737 Change-Id: I7ca1bb46d2923b01587042f0f312d3c3df54c425 Reviewed-on: https://go-review.googlesource.com/c/go/+/208977 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
On darwin, we use libc calls, and cgo is required on ARM and ARM64 so we have TLS set up to save/restore G during C calls. If cgo is absent, we cannot save/restore G in TLS, and if a signal is received during C execution we cannot get the G. Therefore don't send signals (and hope that we won't receive any signal during C execution). This can only happen in the go_bootstrap program (otherwise cgo is required). Fixes #35800. Change-Id: I6c02a9378af02c19d32749a42db45165b578188d Reviewed-on: https://go-review.googlesource.com/c/go/+/208818 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Kyle Shannon authored
Updates #22487 Change-Id: I32dcd604af84e2000196d64bf69c67f81535290a Reviewed-on: https://go-review.googlesource.com/c/go/+/208797 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
-
- 25 Nov, 2019 8 commits
-
-
skanehira authored
Change-Id: Icf6cb06dfdde00de1db5e57b243d7e60a9e4e7ac GitHub-Last-Rev: 45003b0656dec68cf0bc1f32b3de2ab688875524 GitHub-Pull-Request: golang/go#35834 Reviewed-on: https://go-review.googlesource.com/c/go/+/208837Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Fazlul Shahriar authored
Fixes #35790 Change-Id: Ie9df103c5c21b34a378821dfad60804ce4b0cad4 Reviewed-on: https://go-review.googlesource.com/c/go/+/208517Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Jason A. Donenfeld authored
rmdir is a built-in of cmd.exe. It's also an alias in powershell.exe. We want always the cmd.exe on, so specify it explicitly. Fixes #35813 Change-Id: I89723e993ee26a20b42d03b8a725ff10ccf30505 Reviewed-on: https://go-review.googlesource.com/c/go/+/208639 Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Instead of installing shared libraries to GOROOT/pkg, clone the necessary files into a new GOROOT and run there. Given that we now have a build cache, ideally we should not need to install into GOROOT/pkg at all, but we can't fix that during the 1.14 code freeze. Updates #28387 Updates #28553 Updates #30316 Change-Id: I83084a8ca29a5dffcd586c7fccc3f172cac57cc6 Reviewed-on: https://go-review.googlesource.com/c/go/+/208482 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
Otherwise, these tests produce no output, which can make the overall output of all.bash a bit tricky to decipher. Updates #30316 Updates #29062 Change-Id: I33b9e070fd28b9f21ece128e9e603a982c08b7cc Reviewed-on: https://go-review.googlesource.com/c/go/+/208483 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bryan C. Mills authored
It turns out that the relative-path support never worked in the first place. It had been masked by the fact that we ~never invoke overlayDir with an absolute path, which caused filepath.Rel to always return an error, and overlayDir to always fall back to absolute paths. Since the absolute paths seem to be working fine (and are simpler), let's stick with those. As far as I can recall, the relative paths were only a space optimization anyway. Updates #28387 Updates #30316 Change-Id: Ie8cd28f3c41ca6497ace2799f4193d7f5dde7a37 Reviewed-on: https://go-review.googlesource.com/c/go/+/208481 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
diaxu01 authored
This Patch describes NOOP in Go assembly syntax and gives Go assembly example and corresponding GNU assembly example. Change-Id: I9db659cc5e3dc6b1f1450f2064255af8872d4b1c Reviewed-on: https://go-review.googlesource.com/c/go/+/207400 Run-TryBot: eric fang <eric.fang@arm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Dan Scales authored
cgo_mmap.go:mmap() is called by mem_linux.go:sysAlloc(), a low-level memory allocation function. mmap() should be nosplit, since it is called in a lot of low-level parts of the runtime and callers often assume it won't acquire any locks. As an example there is a potential deadlock involving two threads if mmap is not nosplit: trace.bufLock acquired, then stackpool[order].item.mu, then mheap_.lock - can happen for traceEvents that are not invoked on the system stack and cause a traceFlush, which causes a sysAlloc, which calls mmap(), which may cause a stack split. mheap_.lock mheap_.lock acquired, then trace.bufLock - can happen when doing a trace in reclaimChunk (which holds the mheap_ lock) Also, sysAlloc() has a comment that it is nosplit because it may be invoked without a valid G, in which case its callee mmap() should also be nosplit. Similarly, sys_darwin.go:mmap() is called by mem_darwin.go:sysAlloc(), and should be nosplit for the same reasons. Extra gomote testing: linux/arm64, darwin/amd64 Change-Id: Ia4d10cec5cf1e186a0fe5aab2858c6e0e5b80fdc Reviewed-on: https://go-review.googlesource.com/c/go/+/207844Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 24 Nov, 2019 1 commit
-
-
Than McIntosh authored
Skip TestMinusRSymsWithSameName testpoint on MIPS for the time being since it triggers failures on that arch. Will re-enable once the problems are fixed. Updates #35779. Change-Id: I3e6650158ab04a2be77e3db5a5194df3bbb0859e Reviewed-on: https://go-review.googlesource.com/c/go/+/208557Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
- 23 Nov, 2019 4 commits
-
-
Tobias Klauser authored
Use generated code comments following the convention https://golang.org/s/generatedcode. Follow-up for CL 204659 Change-Id: I7a3467ff9477488616b17f059245368d3d82d7a0 Reviewed-on: https://go-review.googlesource.com/c/go/+/208417 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Richard Musiol authored
Because of concurrent goroutines it is possible for multiple event handlers to return at the same time. This was not properly supported and caused the wrong goroutine to continue, which in turn caused memory corruption. This change adds a stack of events so it is always clear which is the innermost event that needs to return next. Fixes #35256 Change-Id: Ia527da3b91673bc14e84174cdc407f5c9d5a3d09 Reviewed-on: https://go-review.googlesource.com/c/go/+/204662 Run-TryBot: Richard Musiol <neelance@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Than McIntosh authored
This adds a new test that builds a small Go program with linked against a *.syso file that is the result of an "ld -r" link. The sysobj in question has multiple static symbols in the same section with the same name, which triggered a bug in the loader in -newobj mode. Updates #35779. Change-Id: Ibe1a75662dc1d49c4347279e55646ee65a81508e Reviewed-on: https://go-review.googlesource.com/c/go/+/208478Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Than McIntosh authored
When the ELF host object loader encounters a static/hidden symbol, it creates a sym.Symbol for it but does not enter it into the sym.Symbols lookup table. Under -newobj mode, this was not happening correctly; we were adding the sym via loader.LookupOrCreate, which resulted in collisions when it encountered symbols with the same name + version + section (this can happen for "ld -r" objects). Fixes #35779. Change-Id: I36d40fc1efc03fc1cd8ae6b76cb6a0d2a957389c Reviewed-on: https://go-review.googlesource.com/c/go/+/208479 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
- 22 Nov, 2019 14 commits
-
-
Dmitri Shuralyov authored
Before May 2018, I mistakenly thought the _suffix naming convention¹ used by examples also applied to tests. Thanks to a code review comment² from Ian Lance Taylor, I have since learned that is not true. This trivial change fixes some collateral damage from my earlier misunderstanding, resulting in improved test naming consistency. ¹ https://golang.org/pkg/testing/#hdr-Examples ² https://go-review.googlesource.com/c/go/+/112935/1/src/path/filepath/path_test.go#1075 Change-Id: I555f60719629eb64bf2f096aa3dd5e00851827cd Reviewed-on: https://go-review.googlesource.com/c/go/+/207446 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Both laptops closing their lids and cloud container runtimes suspending VMs both faced the problem where an idle HTTP connection used by the Transport could be cached for later reuse before the machine is frozen, only to wake up many minutes later to think that their HTTP connection was still good (because only a second or two of monotonic time passed), only to find out that the peer hung up on them when they went to write. HTTP/1 connection reuse is inherently racy like this, but no need for us to step into a trap if we can avoid it. Also, not everybody sets Request.GetBody to enable re-tryable POSTs. And we can only safely retry requests in some cases. So with this CL, before reusing an old connection, double check the walltime. Testing was done both with a laptop (closing the lid for a bit) and with QEMU, running "stop" and "cont" commands in the monitor and sending QMP guest agent commands to update its wall clock after the "cont": echo '{"execute":"guest-set-time"}' | socat STDIN UNIX-CONNECT:/var/run/qemu-server/108.qga In both cases, I was running https://gist.github.com/bradfitz/260851776f08e4bc4dacedd82afa7aea and watching that the RemoteAddr changed after resume. It's kinda difficult to write an automated test for. I gave a lightning talk on using pure emulation user mode qemu for such tests: https://www.youtube.com/watch?v=69Zy77O-BUM https://docs.google.com/presentation/d/1rAAyOTCsB8GLbMgI0CAbn69r6EVWL8j3DPl4qc0sSlc/edit?usp=sharing https://github.com/google/embiggen-disk/blob/master/integration_test.go ... that would probably be a good direction if we want an automated test here. But I don't have time to do that now. Updates #29308 (HTTP/2 remains) Change-Id: I03997e00491f861629d67a0292da000bd94ed5ca Reviewed-on: https://go-review.googlesource.com/c/go/+/204797Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Bryan C. Mills authored
Updates #34347 Change-Id: I6ea02d4737999bf24f5335508b5ed2352b498122 Reviewed-on: https://go-review.googlesource.com/c/go/+/208458 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Jay Conrod authored
The test was comparing a binary built from a list of files to a test build from a named package. That should not (and did not) work. The test now compares two binaries built the same way in different directories. Also add a portion of the test for GOPATH and fix the gccgo portion of the test (verified manually). Fixes #35435 Change-Id: I2535a0011c9d97d2274e5550ae277302dbb91e6f Reviewed-on: https://go-review.googlesource.com/c/go/+/208234 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
In module mode, a non-main package lacks an install target. The location of the .shlib corresponding to a given target is stored in a .shlibname file alongside its install target, so in module mode a non-main package also lacks a .shlibname file. This also implies that such a package cannot be installed with 'go install -buildmode=linkshared', but that is a problem for another day. Fixes #35759 Updates #34347 Change-Id: Id3e0e068266d5fb9b061a59e70f9a65985d4973b Reviewed-on: https://go-review.googlesource.com/c/go/+/208233 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
In CL 208233 I am fixing a panic that occurs only with a specific build mode. I want that test to run on all platforms that support that build mode, but the logic for determining support is somewhat involved. For now, I am duplicating that logic into the cmd/internal/sys package, which already reports platform support for other build flags. We can refactor cmd/go/internal/work to use the extracted function in a followup CL. Updates #35759 Change-Id: Ibbaedde4d1e8f683c650beedd10849bc27e7a6e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/208457 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
Previously, 'go test -v' in this directory would result in a massive dump of go command output, because the test plumbed -v to 'build -x'. This change separates them into distinct flags, so that '-v' only implies the display of default 'go' command output. Updates #30316 Change-Id: Ifb125f35ec6a0bebe7e8286e7c546d132fb213df Reviewed-on: https://go-review.googlesource.com/c/go/+/208232 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
After CL 182657 we no longer hold worldsema across the GC, we hold gcsema instead. However in STW GC mode we don't release worldsema before calling Gosched on the user goroutine (note that user goroutines are disabled during STW GC) so that user goroutine holds onto it. When the GC is done and the runtime inevitably wants to "stop the world" again (though there isn't much to stop) it'll sit there waiting for worldsema which won't be released until the aforementioned goroutine is scheduled, which it won't be until the GC is done! So, we have a deadlock. The fix is easy: just release worldsema before calling Gosched. Fixes #34736. Change-Id: Ia50db22ebed3176114e7e60a7edaf82f8535c1b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/208379 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Michael Anthony Knyszek authored
TestPhysicalMemoryUtilization occasionally fails on some platforms by only a small margin. The reason for this is that it assumes the scavenger will always be able to scavenge all the memory that's released by sweeping, but because of the page cache, there could be free and unscavenged memory held onto by a P which the scavenger simply cannot get to. As a result, if the page cache gets filled completely (512 KiB of free and unscavenged memory) this could skew a test which expects to scavenge roughly 8 MiB of memory. More specifically, this is 512 KiB of memory per P, and if a system is more inclined to bounce around between Ps (even if there's only one goroutine), this memory can get "stuck". Through some experimentation, I found that failures correlated highly with relatively large amounts of memory ending up in some page cache (like 60 or 64 pages) on at least one P. This change changes the test's threshold such that it accounts for the page cache, and scales up with GOMAXPROCS. Because the test constants themselves don't change, however, the test must now also bound GOMAXPROCS such that the threshold doesn't get too high (at which point the test becomes meaningless). Fixes #35580. Change-Id: I6bdb70706de991966a9d28347da830be4a19d3a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/208377 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Jay Conrod authored
Verify that 'go generate' works with -modfile. Also check that go commands starts with 'go generate' do not inherit -modfile, but they should still work if -modfile is set in GOFLAGS. Updates #34506 Change-Id: I5e1f897b4e38e4fdaccc0fbb7a71b8d0e9fc0660 Reviewed-on: https://go-review.googlesource.com/c/go/+/208236 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Bryan C. Mills authored
The tests in this package invoked 'go install -i -buildmode=c-shared' in order to generate an archive as well as multiple C header files. Unfortunately, the behavior of the '-i' flag is inappropriately broad for this use-case: it not only generates the library and header files (as desired), but also attempts to install a number of (unnecessary) archive files for transitive dependencies to GOROOT/pkg/$GOOS_$GOARCH_testcshared_shared, which may not be writable — for example, if GOROOT is owned by the root user but the test is being run by a non-root user. Instead, for now we generate the header files for transitive dependencies separately by running 'go tool cgo -exportheader'. In the future, we should consider how to improve the ergonomics for generating transitive header files without coupling that to unnecessary library installation. Updates #28387 Updates #30316 Updates #35715 Change-Id: I622426a860828020d98f7040636f374e5c766d28 Reviewed-on: https://go-review.googlesource.com/c/go/+/208119 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Bryan C. Mills authored
Also add a -testwork flag to facilitate debugging the test itself. Three of the tests of this package invoked 'go install -i -buildmode=c-archive' in order to generate an archive as well as multiple C header files. Unfortunately, the behavior of the '-i' flag is inappropriately broad for this use-case: it not only generates the library and header files (as desired), but also attempts to install a number of (unnecessary) archive files for transitive dependencies to GOROOT/pkg/$GOOS_$GOARCH_shared, which may not be writable — for example, if GOROOT is owned by the root user but the test is being run by a non-root user. Instead, for now we generate the header files for transitive dependencies separately by running 'go tool cgo -exportheader'. In the future, we should consider how to improve the ergonomics for generating transitive header files without coupling that to unnecessary library installation. Updates #28387 Updates #30316 Updates #35715 Change-Id: I3d483f84e22058561efe740aa4885fc3f26137b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/208117 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hana Kim authored
The profile proto message builder maintains a location entry cache that maps a location (possibly involving multiple user frames that represent inlined function calls) to the location id. We have been using the first pc of the inlined call sequence as the key of the cached location entry assuming that, for a given pc, the sequence of frames representing the inlined call stack is deterministic and stable. Then, when analyzing the new stack trace, we expected the exact number of pcs to be present in the captured stack trace upon the cache hit. This assumption does not hold, however, in the presence of the stack trace truncation in the runtime during profiling, and also with the potential bugs in runtime. A better fix is to use all the pcs of the inlined call sequece as the key instead of the first pc. But that is a bigger code change. This CL avoids the crash assuming the trace was truncated. Fixes #35538 Change-Id: I8c6bae98bc8b178ee51523c7316f56b1cce6df16 Reviewed-on: https://go-review.googlesource.com/c/go/+/207609 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Keith Randall <khr@golang.org>
-
two authored
Change-Id: Ie3495a51ac2021a55e7c1ee43a66d07a5bf2757a GitHub-Last-Rev: b6a6bab3ab840b361021b25cac37eb6891c0fe4b GitHub-Pull-Request: golang/go#35709 Reviewed-on: https://go-review.googlesource.com/c/go/+/207853Reviewed-by: Ian Lance Taylor <iant@golang.org>
-