Search Unity

  1. Unity 2019.1 beta is now available.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. We're looking for insight from anyone who has experience with game testing to help us better Unity. Take our survey here. If chosen to participate you'll be entered into a sweepstake to win an Amazon gift card.
    Dismiss Notice
  4. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  5. Unity 2018.3 is now released.
    Dismiss Notice
  6. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

Stacktraces in macOS crash logs

Discussion in 'OSX' started by Alloc, Dec 18, 2018.

  1. Alloc

    Alloc

    Joined:
    Jun 5, 2013
    Posts:
    212
    Hi,

    when our release players crash on macOS macOS (I suppose?) creates a crash log like this one. Unfortunately it only contains names for the native parts of the stacktraces and not for the .NET code.
    An example of it not showing can be seen in lines 37 - 39.
    It also does not show in lines 473 - 479, and that's part of the thread that caused the crash. Not sure if this is part of the .NET code though.

    Is there any way to have these crash reports give more data on those traces? It's hard to track down what causes these if they only happen to our users and not on our devs / QA people and we don't get any useful stacktraces :(

    Kind regards,
    Chris
     
  2. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    7,590
    Yes, that's a crash log generated by the system. It includes symbol names for all the C++ parts of the framework, but of course when it's executing Mono code, there are no symbol names visible to the system at that point — the Mono runtime is just executing a big pile of bytecode.

    I don't know of any trick to get more out of that. But often you can sort of guess where the problem might be, from the symbols you _can_ see. Here the crash was a std::eek:ut_of_range: basic_string exception, thrown in Thread 35 (holy cows you have a lot of threads!) which was attempting to do a std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::compare(unsigned long, unsigned long, char const*, unsigned long).

    So, look for a worker thread that's doing some string comparison that fits the above signature, that might under some circumstances go out of bounds.
     
  3. Alloc

    Alloc

    Joined:
    Jun 5, 2013
    Posts:
    212
    Well, if it was the first call on a thread that might work. But finding a call on the seventh level, maybe the actual call into the string class being within other .NET library code, is not going to work out without any information.

    Why can't Unity create its own stacktraces like it does on Windows and kinda seems like it does on Linux? Or at least does not by default, but if so how do we get that to work?
     
  4. Alloc

    Alloc

    Joined:
    Jun 5, 2013
    Posts:
    212
    So, no way currently to get real stacktraces? And no way to have Unity create its own crash logs on MacOS like it does on Windows?
     
  5. Alloc

    Alloc

    Joined:
    Jun 5, 2013
    Posts:
    212
    Any feedback on how to get this stuff narrowed down?