Xcode not showing debug info on app crash

This is a highly, highly annoying problem I have been having with Xcode for like a year or two now.


Oftentimes when I'm building and running an iOS/tvOS project from Xcode, and the application crashes, Xcode will not show any information whatsoever about the crash. Nothing. It doesn't show the line of code where the crash happens, or anything. It doesn't even show that a crash happened at all. It just behaves like the application had ended running.


The thing is, the exact same project, when it crashes in the exact same situation, is causing Xcode to show the location of the crash (and all related debug information) on a friend's computer, on his Xcode. So it appears this is a problem with my setup in particular.


It does not make any difference whether I build in debug or release mode. It does not make any difference whether I'm running the project on the simulator or on the device.


This is happening only with some types of crash (such as illegal memory access), while other types of crash do cause Xcode to show debugging information (such as an uncaught exception).


Needless to say, debugging these types of crashes is extremely difficult and annoying when Xcode is of exactly zero help in doing so.

Post not yet marked as solved Up vote post of WarpRulez Down vote post of WarpRulez
5.5k views

Replies

I'm literally doing this in my program's main() function:


int main(int argc, char * argv[]) {
    printf("test1\n");
    *((int*)0) = 5;
    printf("test2\n");


When I run it, it prints "test1" to the console, but nothing else happens. Absolutely nothing. The status text on the top bar of Xcode says "Finished running (this app) on Apple TV", and there's absolutely nothing else. No indication of a crash, nothing. The Runtime issues tab says "no runtime issues".


Moreover, if I replace that write to the zero address with a "@throw(nil)", this is printed to the console:


test1

2018-09-19 11:28:16.608384+0300 (this app)[2329:84209] *** Terminating app due to uncaught exception of class 'nil'

libc++abi.dylib: terminating with uncaught exception of type nil


but nothing else happens in Xcode. Once again, "finished running (this app) on Apple TV", and "no runtime issues". Nothing.


"Just add a breakpoint for "All Exceptions"." When I do that, can you guess what happens? If you guessed "nothing", then you would be correct. No difference. Xcode does not see any exception having been thrown. No breakpoint happens, nothing.


There's something seriously broken with my Xcode setup, and I can't find the reason. The debugger simply does not work. At all.

The status text on the top bar of Xcode says "Finished running (this app) on Apple TV", and there's absolutely nothing else.

Is this just an tvOS? Or on iOS as well?

Does it affect real devices? Or the simulator? Or both?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

It appears that it indeed makes a difference whether I run the app on tvOS or on iOS. When I, for example, do a "@throw("test");" at one point in the app, on tvOS it causes the phenomenon I described (ie. the debugger does not start and Xcode simply behaves like nothing has happened other than the application having ended). However, running it on iOS, either a simulator or a device, causes the debugger to start as it should.


I didn't think of testing whether it makes a difference, but it indeed seems to be so. The problem seems to happen only when running on tvOS (either a simulator or a device).

The problem seems to happen only when running on tvOS (either a simulator or a device).

Weird. Here’s what I did:

  1. Starting with Xcode 10.0 on macOS 10.13.6, I created a new project from the Single View App template.

  2. I replaced the

    main
    function in
    main.m
    with this code:
    int main(int argc, char * argv[]) {
        printf("test1\n");
        *((int*)0) = 5;
        printf("test2\n");
    }

    .

  3. I ran that on the simulator.

  4. It launched and then immediately stopped in the debugger, highlighting line 4.

Can you run those steps in your environment to see what you get?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

When I add those lines to the main() function and run the project on a tvOS simulator from Xcode, it prints "test1" to the Xcode console, and then nothing else happens. The program that was being run just ends, the simulator shows the main menu after a while (as is normal when an application crashes), and Xcode shows absolutely nothing. The top bar of Xcode says "Finished running (this project) on Apple TV", and there is no other reaction. The debugger does not start, nor is the line where the crash happens highlighted.


If I build the project for iOS, and run it on an iOS simulator, then it prints that "test1" to the console, and the debugger starts as it should, highlighting the offending line with a message "Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)". I can write commands into the debugger (such as "bt"), and it works fine.


As commented earlier, this is probably something related to my particular setup, because when the same project is run on a coworker's computer, the debugger starts fine, even when running on tvOS.

As commented earlier, this is probably something related to my particular setup …

Agreed. And yeah, that’s weird.

If you create a new (temporary, just for this test) user account on your Mac, does it also have the problem?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I have been thinking if it could have anything to do with this:


Long time ago I was frustrated by Xcode always printing lots of stuff on the console about, if I remember correctly, the same symbol being implemented in two libraries, and that it's unspecified which one would be used (I'm not 100% it was that kind of message, or if it was something similar), so I searched the net for a way to silence that particular warning. On some random forum somewhere someone gave a solution to this. For the life of me I can't remember what it was, but it might have had something to do with Xcodes defaults, or something.


Much later I realized that it was a pretty horrible "solution" because it didn't only silence that one particular warning, but a whole lot of other warnings and messages, including ones that would be useful. Unfortunately by that point I had absolutely no recollection about what the settings or command was, or where the "solution" was given, or even what the exact Xcode warning was. I don't even know if that setting is restricted to this one project, or if it's global to Xcode (ie. it applies to all projects).


I have been wondering if that could be interfering with Xcode's ability to detect the crash properly and launch the debugger. Feels a bit far-fetched, but who knows. (Given that it affects only tvOS projects but not iOS projects is strange, but I suppose such a setting could be target-specific.)


I wonder if there's a way to reset everything in Xcode to defaults. Including settings that might be somewhere else (eg. in the macOS equivalent of the "system registry". I don't remember what it's called now.)

By the way, I tried something that I should have tried from the very beginning. Somehow I just didn't think of trying it: I created a new tvOS project and made it crash on purpose. With this, Xcode's debugger starts normally, as it should.


Therefore this problem seems to be limited only to this one project, on my setup.

Therefore this problem seems to be limited only to this one project …

Hmmm. The way I’d tackle this is to (temporarily) rip all the source code and libraries out of the project, leaving you with just a

main.m
that deliberately crashes. If the problem reproduces, you know it’s related to build settings. If it doesn’t, it’s related to your source code or libraries. And in the second case, the libraries most likely to cause problems like this are ones related to crash reporting. If you have a custom crash reporter, pull that out and see what you get.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"