12

I, like many others, have had issues with Xcode 6+ crashing. I get the SourceKit crashes as well as full application crashes. On a whim I figured I'd try 6.1.1 (developer member center) and it was worse, a debugger breakpoint now results in a a full application crash. So I said forget it and went back to 6.1, but I still have crashes when putting in a debugger breakpoint.

Apparently this crash with breakpoint only affects the Simulator, physical devices set and stop at breakpoints without an issue. Weird!

It's absolutely maddening! Anyone else getting this?

Things I've tried:

  • remove /Application/Xcode.app/ & ~/Library/Developer/*
  • cleaning the project
  • rebooted my laptop
  • breakpoint for execution on a physical device (<<<<====== This works!!!)
  • slaughtering a chicken and spreading it's blood all over

Head of the stack trace:

Process:         Xcode [7904]
Path:            /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier:      com.apple.dt.Xcode
Version:         6.1 (6604)
Build Info:      IDEFrameworks-6604000000000000~2
App Item ID:     497799835
App External ID: 752282650
Code Type:       X86-64 (Native)
Parent Process:  launchd [185]
Responsible:     Xcode [7904]
User ID:         501

Date/Time:       2014-11-25 12:32:49.348 -0800
OS Version:      Mac OS X 10.9.5 (13F34)
Report Version:  11
Anonymous UUID:  E22980F9-B80B-F985-200A-FE471C623C56


Crashed Thread:  23  <DBGLLDBSessionThread (pid=7957)>

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000001409bdfd0

VM Regions Near 0x1409bdfd0:
    Stack                  000000014093b000-00000001409bd000 [  520K] rw-/rwx SM=COW  thread 22
--> STACK GUARD            00000001409bd000-00000001409be000 [    4K] ---/rwx SM=NUL  stack guard for thread 23
    Stack                  00000001409be000-0000000140a40000 [  520K] rw-/rwx SM=COW  thread 23

Application Specific Information:
ProductBuildVersion: 6A1052d

...

Thread 23 Crashed:: <DBGLLDBSessionThread (pid=7957)>
0   libsystem_pthread.dylib         0x00007fff90eb82cf __mtx_droplock + 17
1   libsystem_pthread.dylib         0x00007fff90eb88f3 pthread_mutex_unlock + 60
2   com.apple.LLDB.framework        0x000000011808f8be lldb_private::Mutex::Locker::~Locker() + 22
3   com.apple.LLDB.framework        0x00000001180ed55f GDBRemoteCommunication::CheckForPacket(unsigned char const*, unsigned long, StringExtractorGDBRemote&) + 2423
4   com.apple.LLDB.framework        0x00000001180ec99e GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote&, unsigned int) + 88
5   com.apple.LLDB.framework        0x00000001181eeb1b GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char const*, unsigned long, StringExtractorGDBRemote&, bool) + 91
6   com.apple.LLDB.framework        0x00000001180f7574 ProcessGDBRemote::DoReadMemory(unsigned long long, void*, unsigned long, lldb_private::Error&) + 216
7   com.apple.LLDB.framework        0x00000001181a452a lldb_private::Process::ReadMemoryFromInferior(unsigned long long, void*, unsigned long, lldb_private::Error&) + 94
8   com.apple.LLDB.framework        0x0000000118171889 lldb_private::ProcessStructReader::ProcessStructReader(lldb_private::Process*, unsigned long long, lldb_private::ClangASTType) + 561
9   com.apple.LLDB.framework        0x0000000118169082 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 354
10  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531
11  com.apple.LLDB.framework        0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433
12  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531
13  com.apple.LLDB.framework        0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433
14  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531
15  com.apple.LLDB.framework        0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433
16  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531
17  com.apple.LLDB.framework        0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433
18  com.apple.LLDB.framework        0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531

...

Cœur
  • 37,241
  • 25
  • 195
  • 267
BK-
  • 527
  • 7
  • 19
  • 5
    "slaughtering a chicken and spreading it's blood all over" That really should have worked. What kind of chicken? – matt Nov 25 '14 at 19:51
  • 1
    More seriously, please try my answer here: http://stackoverflow.com/a/6247073/341994 The two edits at the end are particularly important. Xcode maintains some evil caches, which can become corrupt/stale, and blowing them away can help a lot. – matt Nov 25 '14 at 19:55
  • Thanks for the suggestions. I tried all of the clearing, but the issue still results. I updated my question with more details and also just found out this only happens on the Simulator. Physical device does not crash the debugger breakpoints. – BK- Nov 25 '14 at 20:36
  • Well, back to the chicken... :( At least you've got a workaround so you can keep developing. Meanwhile, if you can package this up as a reproducible case, it's obviously a superb bug report. Xcode crashing is Not Nice. – matt Nov 25 '14 at 20:58
  • 1
    Have you deleted all breakpoints and only set a single one? and of course, you should file a bug. – theguy Nov 25 '14 at 22:06
  • Absolutely have deleted all breakpoints. I've submitted a number of crash reports, but not a bug. I have no clue how installing 6.1.1 and then going back to 6.1 causes this much pain! :( I'll file a bug report! – BK- Nov 25 '14 at 23:02
  • Apple bug report: 19081280 – BK- Nov 25 '14 at 23:10
  • 1
    I lied, it does crash on a phone. It's a very specific breakpoint that is crashing both xcode 6.1 and 6.1.1. AAARRGGGHHHHH!!!! – BK- Nov 26 '14 at 00:55
  • You give me hope when I read working on device, but then later read it is not working :( So I try and failed for me too. Device and Simulator crash xCode if on my main app (Start to write so swift inside), but no crash if the breakpoint is on my subproject (100% percent swift). I do the three recommandation of Matt but still the same. – Dam Dec 03 '14 at 16:08
  • Sorry I never followed up. Apple closed my bug as "Duplicate" and that was that. They referenced issue number 18841218, which appears to still be open as of today. Here's to hoping XCode 7 fixes it!! – BK- Jan 08 '15 at 22:18
  • Have a place where it crash on a real device (hitting the breakpoint) but not on the simulator. Also, when our app crash (say, hitting a nil), tying to go back on the thread-tree cause Xcode to blow. I usually have about 2 seconds to get a sneak of line of code it stopped on. Otherwise, have to resort to flood the code with with prints. – bauerMusic Jan 23 '15 at 06:40
  • As a quick follow-up, we went back to Obj-C and we have no further crashing. We'll try again with swift in a later release. – BK- Feb 05 '15 at 05:39

1 Answers1

11

There have been many solutions proposed over the years for this kind of bizarre Xcode behavior, so I have included all those steps as well; however, I have added a few of my own that (when done together and in order) have never failed to resolve every weird Xcode issue that I have come across.

PLEASE NOTE: Doing ALL of these steps (in order) can be CRITICAL. I realize that some of them at first glance seem like overkill or like they should not matter, but my experience has shown that each step plays a part in getting Xcode back into proper working order. Therefore, I do NOT recommend skipping any steps or changing their order.

With that said, if you discover the need to tweak the steps below, please do post a comment. Xcode does change constantly so these steps may also need change as well over time.

After Xcode crashes:

  1. If simulator is still running make sure to select IOS Simulator->Reset Content And Settings before closing it.

  2. Close Simulator (CMD-Q)

  3. Window -> Organizer -> Delete derived data

  4. If debugging on ANY devices, delete the app from the device and REBOOT the device completely.

  5. Launch Xcode

  6. Remove All breakpoints

  7. Product -> (hold down Alt/option key) Clean Build Folder

  8. Product -> Clean

  9. Close Xcode again via Xcode->Quit Xcode (NOTE: Must be a GRACEFUL Exit, so Xcode can properly do a complete shutdown/cleanup cycle)

  10. Reboot your Mac

  11. Launch Xcode

  12. If running in simulator, pick a different device to simulate than when it crashed.

  13. Do a test run of your app (with no breakpoints)

  14. If all goes well, start adding a breakpoints (All Exceptions is always a good starting point).

HAIL MARY CLAUSE (a.k.a. "The Corbomite Maneuver"): If doing all the above did not work then re-perform all the above steps again, but insert the following step between steps 9 and 10: 9A) Delete Xcode app and re-install Xcode.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Questor
  • 376
  • 4
  • 8
  • I did all of that, but thank you for documenting it more completely than I had. It appears that even after doing everything listed above, eventually it will crash again. *sad face* There is a 6.2 in the works, maybe that will bring more stability. – BK- Feb 06 '15 at 17:52
  • 1
    The above is really to fix XCode when it gets into a bad state. However, the cause of the bad state could be related to the code you are running... for example, doing tons of logging to the console will inevitably get XCode to start crashing. Also, bad memory pointers in C/C++ (and even objC) can make any environment a bit wonky over time (even when caught). Point is that the above is meant to get XCode back to normal... at which point I would try to narrow down the cause of the issue in the project you are trying to run. i.e.You still need to fix the root cause for XCode to remain stable. – Questor Feb 07 '15 at 00:40
  • Good point! I have found the same. Cleaning the whole thing out can sometimes help find the root cause of the crash. Thanks for the clarification. – BK- Feb 09 '15 at 17:35
  • 1
    i was skeptical, but it really worked for me, with a crash occurring in 6.4 when putting a breakpoint inside a callback of a callback of a callback :) – manmal Jul 08 '15 at 12:43