When a test binary runs for too long, the go command sends it a
SIGQUIT to force a backtrace dump. On Android, the exec wrapper
will instead receive the signal and dump its backtrace.
Forward SIGQUIT signals from the wrapper to the wrapped process
to gain useful backtraces.
Inspired by issuse 25519; this CL would have revealed the hanging
test directly in the builder log.
Change-Id: Ic362d06940d261374343a1dc09366ef54edaa631
Reviewed-on: https://go-review.googlesource.com/114137
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Introduce GOANDROID_ADB_FLAGS for additional flags to adb invocations.
With GOANDROID_ADG_FLAGS, the Android builders can distinguish between
emulator and device builds.
Change-Id: I11729926a523ee27f6a3795cb2cfb64a9454f0a5
Reviewed-on: https://go-review.googlesource.com/88795
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
On Android, the exec wrapper passes on output from adb to its parent
process by passing on os.Stderr and os.Stdout to adb. If the adb
process somehow hangs, it will keep stderr and stdout will open, in turn
blocking go test from ever returning from its cmd.Wait() even though
it has killed the exec wrapper process.
Break the short circuit by introducing a wrapper between adb and the
exec wrapper, preventing os/exec.Run from passing along the raw
file descriptors for os.Stdout and os.Stderr.
(Hopefully) fixes occasional indefinite hangs on the Android builder.
Change-Id: I1188211fbde79b4a66bf93ff8e9d0091abf34560
Reviewed-on: https://go-review.googlesource.com/42271
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Before, the Android exec wrapper expected the trailing exit code
output on its own line, like this:
PASS
exitcode=0
However, some tests can sometimes squeeze in some output after
the test harness outputs "PASS" and the newline. The
TestWriteHeapDumpFinalizers test is particularly prone to this,
since its finalizers println to standard out. When it happens, the
output looks like this:
PASS
finalizedexitcode=0
Two recent failures caused by this race:
https://build.golang.org/log/185605e1b936142c22350eef22d20e982be53c29https://build.golang.org/log/e61cf6a050551d10360bd90be3c5f58c3eb07605
Since the "exitcode=" string is always echoed after the test output,
the fix is simple: instead of looking for the last newline in the
output, look for the last exitcode string instead.
Change-Id: Icd6e53855eeba60b982ad3108289d92549328b86
Reviewed-on: https://go-review.googlesource.com/23750
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This change includes the cleanup of temporary files created during
the binary execution as well.
Change-Id: Ic01a0a537d1daafcaa3acda1ec344aff5dcddfc2
Reviewed-on: https://go-review.googlesource.com/2903
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL adjusts code referring to src/pkg to refer to src.
Immediately after submitting this CL, I will submit
a change doing 'hg mv src/pkg/* src'.
That change will be too large to review with Rietveld
but will contain only the 'hg mv'.
This CL will break the build.
The followup 'hg mv' will fix it.
For more about the move, see golang.org/s/go14nopkg.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/134570043
