1
0
mirror of https://github.com/golang/go synced 2024-11-27 03:31:29 -07:00
Commit Graph

8 Commits

Author SHA1 Message Date
David Crawshaw
00e0fe4b95 misc/ios: retry loop to handle builder flakiness
After moving the darwin/arm builder to new hardware several new flaky
error messages appeared. This provided enough information to Google
to make it clear that iOS build systems have been flaky for many
years, and that is unlikely to change any time soon.

However, all of the pain of lldb and using a breakpoint early in
program initialization gives us an advantage: all install and
initialization flakiness appears to happen before the Go program ever
gets going. So if we see an error or we timeout before we reach our
breakpoint (before any test code has executed), we can assume it is
the fault of the builder and restart without risking hiding a flaky
Go test.

This code has successfully processed the last 8 builds. I am hopeful.

Change-Id: Ide24aaae4fa7bdab9d8f4432bb85d8f2256c7606
Reviewed-on: https://go-review.googlesource.com/8241
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-30 18:11:07 +00:00
David Crawshaw
713451a097 misc/ios: simplify breakpoint timeout
The clever partial timer I added interacts badly with iOS app launch
timeout termination. A fixed timeout will be easier to debug.

Change-Id: I6eb4ee5f1431539f00fa707e8cde6f3cf86983fc
Reviewed-on: https://go-review.googlesource.com/8083
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-25 17:26:03 +00:00
David Crawshaw
ed92862522 misc/ios: timeout and continue waiting for getwd
Split out from cl/8024 for clarity and improved approach.

Rarely, "stop reason = breakpoint" does not appear in the lldb stop
text. However the program is ready to proceed. To be a little more
robust about those cases, we wait for two seconds, and if that text
doesn't appear but a prompt does we continue and hope for the best.
Worst case, this results in a harder to read failure message.

Change-Id: Ib20aa92564cdccefd2b7260417c647cd44122b66
Reviewed-on: https://go-review.googlesource.com/8080
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-25 16:31:38 +00:00
David Crawshaw
7ff6254c50 misc/ios: run lldb commands much more carefully
We now wait until we see the completed prompt from a command before
proceeding. This seems to cut down on a spurious error I have seen
this afternoon.

Change-Id: Ic0a3481d8c265c3c3b4449ec7ac1c2752b85b0b6
Reviewed-on: https://go-review.googlesource.com/6691
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-03 23:06:45 +00:00
David Crawshaw
1fdeb6b58a misc/ios: extra stdout check before run
On one recent job I saw an unexpected SIGSTOP, which I suspect is
simply the job timeout. But the lack of other diagnostics suggests
lldb just didn't see the "run" command.

-----

process handle SIGHUP  --stop false --pass true --notify false
process handle SIGPIPE --stop false --pass true --notify false
process handle SIGUSR1 --stop false --pass true --notify false
process handle SIGSEGV --stop false --pass true --notify false
process handle SIGBUS  --stop false --pass true --notify false
breakpoint set -n getwd
run
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGHUP      true   false  false
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGPIPE     true   false  false
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGUSR1     true   false  false
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGSEGV     true   false  false
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGBUS      true   false  false
(lldb) Breakpoint 1: where = libsystem_c.dylib`getwd, address = 0x2f7f7294
(lldb) Process 23755 stopped
* thread #1: tid = 0x104c02, 0x1febb000 dyld`_dyld_start, stop reason = signal SIGSTOP
    frame #0: 0x1febb000 dyld`_dyld_start
dyld`_dyld_start:
-> 0x1febb000:  mov    r8, sp
   0x1febb004:  sub    sp, sp, #0x10
   0x1febb008:  bic    sp, sp, #0x7
   0x1febb00c:  ldr    r3, [pc, #112]            ; _dyld_start + 132
(lldb) go_darwin_arm_exec: timeout (stage br getwd)
FAIL	compress/gzip	359.226s

Change-Id: Ifc2123f5ceaa6d3f9b31bb5cb6e77a2c8ec23818
Reviewed-on: https://go-review.googlesource.com/6613
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-03 20:03:32 +00:00
David Crawshaw
66416c00eb misc/ios: more predictable zoneinfo.zip location
See golang.org/cl/6511.

Change-Id: I2145a42877ed6b78400f29c2ef18969870dab5c3
Reviewed-on: https://go-review.googlesource.com/6512
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-03 01:49:56 +00:00
David Crawshaw
d460b6e5c6 misc/ios: add go_darwin_arm_exec script
This script is getting very close to complete, and is complex enough
that I'd like to get what's there so far reviewed. With it the builder
is left failing on eight packages. Two of those involve correcting
GOROOT which may need modifications to this script, the others are
either a unix sockets bug I have to hunt down or are caused by lldb
getting stuck on SIGSEGV, a TODO.

Change-Id: I5ff933800167b6764b51ad195da7dcda61d59ff8
Reviewed-on: https://go-review.googlesource.com/6404
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-02 19:42:30 +00:00
Shenghou Ma
f961a99a35 misc/ios: add README and wrapper script to ease cross-compiling for darwin/arm
Fixes #837.

Change-Id: I2d601504addbd220b304d32d587144d2a702f753
Reviewed-on: https://go-review.googlesource.com/2127
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-02-06 05:50:10 +00:00