Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: signal_unix.crash() does not trigger crash reporters on iOS #20392

Closed
steeve opened this issue May 17, 2017 · 27 comments

Comments

Projects
None yet
6 participants
@steeve
Copy link
Contributor

commented May 17, 2017

What version of Go are you using (go version)?

go version go1.8.1 darwin/amd64

What operating system and processor architecture are you using (go env)?

darwin/amd64
darwin/arm64

What did you do?

Run this sample program:

package main

import "runtime/debug"

func main() {
	debug.SetTraceback("crash")

	var c []int
	c[0] = 0
}

What did you expect to see?

  • It should crash with a SIGABRT

What did you see instead?

  • It exits with exit(2)

Notes

According to

func crash() {
this is expected behaviour, and the reason is quite compelling.
I traced it back to 5146a93#diff-51306f0b403ee6e698224ae3ae071c21R101, which is 4 years ago.

I did try to comment this code to see if I would still get the same behaviour as described by the commit/code, and turns out I do not.
Running the above program on go version devel +c20e545 Wed May 17 01:30:51 2017 +0000 darwin/amd64, OS X crash reported correctly identified the crash and the file is pretty small:

$ ls -l ~/Library/Logs/DiagnosticReports
total 1392
-rw-------@ 1 steeve  staff    7112 May 17 12:00 main_2017-05-17-120042_macbook.crash
-rw-------@ 1 steeve  staff    7112 May 17 12:20 main_2017-05-17-122011_macbook.crash
-rw-------@ 1 steeve  staff    6978 May 17 12:20 main_2017-05-17-122053_macbook.crash

So I think this code is outdated and can be dropped, thus honouring the tracebackCrash flag properly. However, I'm not sure since when.
All I can say is that it works fine on my OS X install, which is 10.12.4. So at minimum the code could disable the silencing starting this 10.12 perhaps:

Darwin macbook.local 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64

@ianlancetaylor ianlancetaylor added this to the Go1.9Maybe milestone May 17, 2017

@aclements

This comment has been minimized.

Copy link
Member

commented Jul 18, 2017

Hi @steeve. Sadly, the files in DiagnosticReports are not core dumps. Those are just text logs with some basic information about crashes. I just checked, and core dumps on OS X 10.12.5 (which appear in /cores) are still linear dumps of memory and humongous even for trivial programs.

@aclements aclements closed this Jul 18, 2017

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Jul 18, 2017

Thank you for looking into this @aclements

Indeed they are not core dumps, but I am not able to reproduce the humongous core dump you talk about with the example program I have pasted up there. Could you give me more details about how to generate them?
Also, this completely breaks potential crash reporting on iOS, so do you think this could be limited to darwin/amd64 ?

@aclements

This comment has been minimized.

Copy link
Member

commented Jul 18, 2017

Indeed they are not core dumps, but I am not able to see the reproduce the humongous core dump you talk about with the example program I have paster up there. Could you give me more details about how to generate them?

At a minimum, you have to set ulimit -c unlimited in your shell, which I believe requires root on OS X. (/cc @rsc, since he did the experiment)

Also, this completely breaks potential crash reporting on iOS, so do you think this could be limited to darwin/amd64 ?

Can you say more about how crash reporting works on iOS? E.g., if it's going to have the same core file problem as Darwin, then I don't think we can enable this.

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Jul 18, 2017

Indeed I may not have set the ulimit to unlimited, which may explain why I was not able to reproduce it.

Most crash reporters (Crashlytics, Sentry, etc...) on iOS work by hooking SIGABRT (among other things such as global exception handlers etc...). The issue at hand is that in case of a panic, it will never be sent, thus will not trigger the hooks they install, thus the crash will be silent.

When I commented the code the crash reporting worked, but the traceback was wrong (that's another story). I would be very surprised that ulimit would be unlimited in an iOS sandbox, however.

@aclements

This comment has been minimized.

Copy link
Member

commented Jul 18, 2017

@aclements aclements changed the title runtime: signal_unix.crash() does not generate core dumps on darwin/*64 runtime: signal_unix.crash() does not trigger crash reporters on iOS Jul 18, 2017

@eliasnaur

This comment has been minimized.

Copy link
Contributor

commented Jul 18, 2017

That's funny, I'm sitting with a similar problem on Android. Could you try

https://go-review.googlesource.com/c/49590/ ?

As per Ian's comments, it might not be the correct fix, but will tell us if the problem is the same.

@eliasnaur eliasnaur reopened this Jul 18, 2017

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Jul 18, 2017

hey @eliasnaur, sure, will do

@gopherbot

This comment has been minimized.

Copy link

commented Jul 18, 2017

CL https://golang.org/cl/49590 mentions this issue.

@eliasnaur

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2017

You probably need to apply https://go-review.googlesource.com/c/49770 as well, to make 49590 effective on darwin/arm64.

@aclements aclements modified the milestones: Go1.10, Go1.9Maybe Jul 19, 2017

gopherbot pushed a commit that referenced this issue Aug 10, 2017

Elias Naur
runtime: when dying from a signal use the previous signal handler
Before this CL, whenever the Go runtime wanted to kill its own
process with a signal dieFromSignal would reset the signal handler
to _SIG_DFL.

Unfortunately, if any signal handler were installed before the Go
runtime initialized, it wouldn't be invoked either.

Instead, use whatever signal handler was installed before
initialization.

The motivating use case is Crashlytics on Android. Before this CL,
Crashlytics would not consider a crash from a panic() since the
corresponding SIGABRT never reached its signal handler.

Updates #11382
Updates #20392 (perhaps even fixes it)
Fixes #19389

Change-Id: I0c8633329433b45cbb3b16571bea227e38e8be2e
Reviewed-on: https://go-review.googlesource.com/49590
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@eliasnaur

This comment has been minimized.

Copy link
Contributor

commented Aug 10, 2017

@steeve, both CLs are now in, hopefully fixing this issue.

@gopherbot

This comment has been minimized.

Copy link

commented Aug 11, 2017

Change https://golang.org/cl/55032 mentions this issue: runtime: fix crashing with foreign signal handlers on Darwin

gopherbot pushed a commit that referenced this issue Aug 11, 2017

Elias Naur
runtime: fix crashing with foreign signal handlers on Darwin
The dieFromSignal runtime function attempts to forward crashing
signals to a signal handler registered before the runtime was
initialized, if any. However, on Darwin, a special signal handler
trampoline is invoked, even for non-Go signal handlers.

Clear the crashing signal's handlingSig entry to ensure sigtramp
forwards the signal.

Fixes the darwin/386 builder.

Updates #20392
Updates #19389

Change-Id: I441a3d30c672cdb21ed6d8f1e1322d7c0e5b9669
Reviewed-on: https://go-review.googlesource.com/55032
Run-TryBot: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@aclements

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

@steeve, can you confirm whether Go on tip now triggers crash reporters on iOS?

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Aug 18, 2017

Okay, just got the time to properly test this. Unfortunately it does not work.

go version devel +839b28246f Fri Aug 18 16:55:11 2017 +0000 darwin/amd64

Here is my test code:

import (
	"runtime/debug"
)

func init() {
	debug.SetTraceback("crash")
}

func panicOnNullValue() {
	var c []int
	c[0] = 0
}

func panicForReal() {
	panic("DID PANIC")
}

func Panic() {
	panicOnNullValue()
}

func Panic2() {
	panicForReal()
}

Both of these do not generate crash reports on iOS (while they correctly dump to stdout).

The good news it, it does generate a SIGABRT, which was not the case with go 1.8.3. The bad news is that Crashlytics doesn't see it somehow (never sends the report at next app start).

I believe this may be because the sig handlers might be set too early by Go on iOS, since you need to install them with in the Application delegate (application main on iOS), while on Android, the libgojni trampoline does it after.

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Aug 18, 2017

Another thing: if I manually raise SIGABRT with Swift, the crash is correctly reported.

    @IBAction func buttonUp(_ sender: Any) {
        Crash.CrashPrint()
        raise(SIGABRT)
    }

Whereas this does not:

    @IBAction func buttonUp(_ sender: Any) {
        Crash.CrashPrint()
        Crash.CrashPanic2()
    }

Note that Crash.CrashPrint() does nothing but print something, to ensure the Go runtime is alive and initialized.

The weird thing is that SIGBART is raised in the second case, as Xcode breaks on it.

@aclements

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Aug 18, 2017

After reading 5500c9c in detail, I do believe this is because of a race between Crashlytics init and Go.

Crashlytics installs its handlers when asked (in the app main), but I think the Go runtime is initialized before (being a static library). Since the handlers are saved at runtime init, this may be too early.

I suspect this works on Android because of the trampoline.

Sorry I did not have time to check this earlier...

@bcmills

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

There is probably a second change we need to do on top of https://golang.org/cl/55032: we should first try raising the signal without reinstalling the sigFwd handler. If the resulting signal forwards to the runtime's handler, or if the process survives the signal with whatever handler is currently in place, then we should forward to sigFwd (or reinstall SIG_DFL and crash).

@gopherbot

This comment has been minimized.

Copy link

commented Aug 19, 2017

Change https://golang.org/cl/57291 mentions this issue: runtime: forward crashing signals to late handlers

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Aug 19, 2017

Happy to report that CL 57291 properly makes crash detectors (Crashlytics in my case) detect the crash !

However, the stack trace is lost:

Crashed: com.apple.main-thread
0  testapp-swift                  0x1000950b8 runtime.raiseproc + 24
1  testapp-swift                  0x1000d1b68 CrashPanic + 12
2  testapp-swift                  0x100048798 ViewController.buttonUp(Any) -> () (ViewController.swift:85)
3  testapp-swift                  0x100048800 @objc ViewController.buttonUp(Any) -> () (ViewController.swift)
4  UIKit                          0x1951a5484 -[UIApplication sendAction:to:from:forEvent:] + 96
5  UIKit                          0x1951a5404 -[UIControl sendAction:to:forEvent:] + 80
6  UIKit                          0x19518f8b8 -[UIControl _sendActionsForEvents:withEvent:] + 452
7  UIKit                          0x1951a4cf0 -[UIControl touchesEnded:withEvent:] + 584
8  UIKit                          0x1951a4818 -[UIWindow _sendTouchesForEvent:] + 2484
9  UIKit                          0x19519fa60 -[UIWindow sendEvent:] + 2988
10 UIKit                          0x19517052c -[UIApplication sendEvent:] + 340
11 UIKit                          0x19595da54 __dispatchPreprocessedEventFromEventQueue + 2736
12 UIKit                          0x1959574bc __handleEventQueue + 784
13 CoreFoundation                 0x18f2c4278 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
14 CoreFoundation                 0x18f2c3bc0 __CFRunLoopDoSources0 + 524
15 CoreFoundation                 0x18f2c17c0 __CFRunLoopRun + 804
16 CoreFoundation                 0x18f1f0048 CFRunLoopRunSpecific + 444
17 GraphicsServices               0x190c76198 GSEventRunModal + 180
18 UIKit                          0x1951db2fc -[UIApplication _run] + 684
19 UIKit                          0x1951d6034 UIApplicationMain + 208
20 testapp-swift                  0x100049ff4 main (AppDelegate.swift:14)
21 libdispatch.dylib              0x18e1d45b8 (Missing)

I am using the same code as above, that is calling Panic() from GoMobile, which is CrashPanic().

The trace should be:

runtime.raiseproc
github.com/steeve/mypkg.panicOnNullValue
github.com/steeve/mypkg.Panic
CrashPanic
...

The framework was generated with:

gomobile bind -v -tags=lldb -target=ios -prefix "" github.com/steeve/crash

I'm thinking it may be due to missing debug/symbols information ?

@eliasnaur

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2017

Glad to hear it works! Please raise a new issue for the missing stack trace. It is a problem on Android as well, and is orthogonal to this issue. It could be as simple as missing framepointers on arm/arm64, in which case

https://groups.google.com/forum/#!topic/golang-dev/v1TxCJNemPY

sounds like good news, at least for arm64.

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Aug 19, 2017

That's great, will do!

gopherbot pushed a commit that referenced this issue Aug 29, 2017

Elias Naur
runtime: forward crashing signals to late handlers
CL 49590 made it possible for external signal handlers to catch
signals from a crashing Go process. This CL extends that support
to handlers registered after the Go runtime has initialized.

Updates #20392 (and possibly fix it).

Change-Id: I18eccd5e958a505f4d1782a7fc51c16bd3a4ff9c
Reviewed-on: https://go-review.googlesource.com/57291
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@eliasnaur

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2017

CL 57291 was reworked before going in. Can you verify crashes are still propagated as you expect on tip? If so, you can close this issue.

@aclements

This comment has been minimized.

Copy link
Member

commented Nov 8, 2017

Ping @steeve. Can you re-test with tip to make sure the reworked CL still fixes the issue? Thanks!

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Nov 10, 2017

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Nov 14, 2017

Confirmed working! However, there is still the issue regarding the stack traces which are all wrong:

# Crashlytics - plaintext stacktrace downloaded by Steeve Morin at Tue, 14 Nov 2017 00:11:12 GMT
# Platform: ios
# Application: testapp-swift
# Version: 1.0 (1)
# Issue #: 2
# Issue ID: 591c99d0be077a4dccdaf367
# Session ID: e591a6fc5b8641d8b4571ce7df6c11f4_4c0f40a1c8d011e7a1bd56847afe9799_0_v2
# Date: 2017-11-14T00:10:00Z
# OS Version: 11.1.1 (15B150)
# Device: iPhone X
# RAM Free: 7.2%
# Disk Free: 69.1%

#0. Crashed: com.apple.main-thread
0  testapp-swift                  0x1048d5798 runtime.raiseproc + 24
1  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
2  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
3  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
4  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
5  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
6  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
7  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
8  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
9  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
10 testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60

--

#0. Crashed: com.apple.main-thread
0  testapp-swift                  0x1048d5798 runtime.raiseproc + 24
1  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
2  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
3  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
4  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
5  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
6  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
7  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
8  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
9  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
10 testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60

#1. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#2. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d76fa0 _pthread_wqthread + 884
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#3. Thread
0  libsystem_pthread.dylib        0x183d76c1c start_wqthread + 122

#4. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d77134 _pthread_wqthread + 1288
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#5. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d77134 _pthread_wqthread + 1288
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#6. com.apple.uikit.eventfetch-thread
0  libsystem_kernel.dylib         0x183c44bc4 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x183c44a3c mach_msg + 72
2  CoreFoundation                 0x1840f5c74 __CFRunLoopServiceMachPort + 196
3  CoreFoundation                 0x1840f3840 __CFRunLoopRun + 1424
4  CoreFoundation                 0x184013fb8 CFRunLoopRunSpecific + 436
5  Foundation                     0x184a3d6e4 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 304
6  Foundation                     0x184a5cafc -[NSRunLoop(NSRunLoop) runUntilDate:] + 96
7  UIKit                          0x18e1472f4 -[UIEventFetcher threadMain] + 136
8  Foundation                     0x184b3e860 __NSThread__start__ + 996
9  libsystem_pthread.dylib        0x183d7831c _pthread_body + 308
10 libsystem_pthread.dylib        0x183d781e8 _pthread_body + 310
11 libsystem_pthread.dylib        0x183d76c28 thread_start + 4

#7. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d76fa0 _pthread_wqthread + 884
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#8. Thread
0  testapp-swift                  0x1048d5b44 runtime.mach_semaphore_timedwait + 20
1  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
2  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
3  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
4  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
5  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
6  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
7  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
8  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
9  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
10 testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192

#9. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#10. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#11. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#12. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#13. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#14. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#15. com.twitter.crashlytics.ios.MachExceptionServer
0  libsystem_kernel.dylib         0x183c44bc4 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x183c44a3c mach_msg + 72
2  testapp-swift                  0x104918aa4 CLSMachExceptionServer + 100
3  libsystem_pthread.dylib        0x183d7831c _pthread_body + 308
4  libsystem_pthread.dylib        0x183d781e8 _pthread_body + 310
5  libsystem_pthread.dylib        0x183d76c28 thread_start + 4

#16. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d77134 _pthread_wqthread + 1288
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#17. com.apple.NSURLConnectionLoader
0  libsystem_kernel.dylib         0x183c44bc4 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x183c44a3c mach_msg + 72
2  CoreFoundation                 0x1840f5c74 __CFRunLoopServiceMachPort + 196
3  CoreFoundation                 0x1840f3840 __CFRunLoopRun + 1424
4  CoreFoundation                 0x184013fb8 CFRunLoopRunSpecific + 436
5  CFNetwork                      0x18477e264 +[NSURLConnection(Loader) _resourceLoadLoop:] + 404
6  Foundation                     0x184b3e860 __NSThread__start__ + 996
7  libsystem_pthread.dylib        0x183d7831c _pthread_body + 308
8  libsystem_pthread.dylib        0x183d781e8 _pthread_body + 310
9  libsystem_pthread.dylib        0x183d76c28 thread_start + 4
@aclements

This comment has been minimized.

Copy link
Member

commented Nov 14, 2017

@steeve, great! Thanks for checking. I'm going to close this issue as fixed. Could you open a new issue about the stack traces? Thanks!

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Nov 14, 2017

@golang golang locked and limited conversation to collaborators Nov 14, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.