Diagnosing crashes on MacOS X

[Lisias]

Well... The last few days I got somewhat overwhelmed by a series of crashes on my MacOS box that I didn't diagnosed correctly, and found myself chasing ghosts. =/

Not one of my brightest times. =P

This thread is my attempt to gather together a knowledge base of MacOS specific issues and, with luck, minimize the time spent on crashing KSP and maximize the time spent crashing crafts on KSP. :-)

The proposed "rules" are simple: a post per 'problem x solution'. I don't plan to use this as a generic support thread - I think that help for unknown problems should be get in dedicated threads. My plan for this one is to be a place where one can try to find a solution for a MacOS specific problem before asking for help.

So, let the games begin. :-)

Edited May 13, 2018 by Lisias
deleting the merged content - I plan to have one post por Solution.

[Lisias]

On my MacMini mid 2011 (a very expensive potato machine!), I'm constantly running out of VRAM (or something similar). Since my box is dual headed (two monitors), this issues appears to be happens more to me than on a single head setup.

The way to diagnose this is asking for the report once the crash happens, and see where the crash happened.

On the resport itself, check if a SIGABRT were issued from the UnityGfxDeviceWorker thread as the example:

If it's your case, there's a very good chance that you overrun the VRAM limits.

The solution for this problem is to reduce your texturing footprint. Usually, by deleting the last AddOn you installed but I also solved this by deleting visual enhancements Plug In, mainly the ones that adds or switches textures on the game.

It's a choice you must make: more parts with small textures or keeping large textures used on skies, planets, etc.

Edited May 13, 2018 by Lisias

[Lisias]

This one took me some blood, sweat and tears. I mistakenly diagnosed this as being run out of VRAM, and then deleted lots and lots of AddOns without success.

Then I thought it could be a unholy interaction between some Plug-Ins, and took a lot of time playing combinatorial analysis with my installed plugins. No pattern detected.

Just then I though on really looking into that report again:

Process:               KSP [21826]
Path:                  /Users/USER/*/KSP.app/Contents/MacOS/KSP
Identifier:            unity.Squad.Kerbal Space Program
Version:               1.4.3 (0)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           KSP [21826]
User ID:               505

Date/Time:             2018-05-11 07:30:21.553 -0300
OS Version:            Mac OS X 10.12.6 (16G1314)
Report Version:        12
Anonymous UUID:        xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx


Time Awake Since Boot: 65000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  MainThrd  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

VM Regions Near 0:

And voilà. New issue. :-(

It ended up being a issue with a old copy of "000_USITools", more specifically, USITools.dll .

I probably had a VRAM issue before, but while trying to figure out what AddOn I would delete and which one I need to keep due my vessels, I probably reinstalled a Add On with a old USITools.dll that, by some reason I just could not figure out, crashed my machine.

Such old version of USITools.dll may be not the cause, just one (of possible many) trigger - but nevertheless, I solved my problem this time by installing the newest release of USITools.

So, if you ever get this SIGABRT from com.apple.main-thread, first check the 000_USITools subdir to see if you have the most recent one. If not, update to the newest one for your KSP installment (I'm using 1.4.3).

If after updating the USITools you still have the issue, make a copy of your installment and start to delete AddOns one by one until the crash is gone, and then install back all the others.

If success, please report on this thread so others can save their time! :-)

Edited May 13, 2018 by Lisias

[Lisias]

This one is interesting.

Appears to exist a memory leak somewhere on Unity that consistently crashes my machine if I leave KSP running by it's own by the night.

Reproducing this is easy: turn off your computer energy saving (so it doesn't sleep before the crash), fire up KSP and leave the machine alone by the night. I didn't measured the time it needs to crash, but it's less than 7 hours. ;-)

The interesting part is that, by all means, the crash report is essentially the same as when you overrun your VRAM. It's essentially equal, except by the physical addresses of the routines and process specifics data.

So, I'm guessing the memory leak is on the VRAM memory management.

Since the crash report is virtually identical to the previous, I'm quoting a snip from the Player.log from Unity:

Native stacktrace:

	0   libsystem_kernel.dylib              0x00007fffc5640d42 __pthread_kill + 10
	1   libsystem_c.dylib                   0x00007fffc55a6420 abort + 129
	2   libGPUSupport.dylib                 0x00007fffbd9c4c05 gpusKillClient + 83
	3   AppleIntelHD3000GraphicsGLDriver    0x000000010e002e0e _ZN13GhalInterface16getCommandBufferEPPhS1_PjS2_ + 158
	4   AppleIntelHD3000GraphicsGLDriver    0x000000010e01eeb1 _ZN6GHAL3D24CPrivateCommandTransport18FlushCommandBufferENS_10FLUSH_TYPEEh + 273
	5   AppleIntelHD3000GraphicsGLDriver    0x000000010e01ec52 g575SubmitPacketsToken + 69
	6   AppleIntelHD3000GraphicsGLDriver    0x000000010e2703ea glrBindContextDrawFramebuffer + 2369
	7   libGPUSupport.dylib                 0x00007fffbd9c7a3f gldUpdateDrawFramebuffer + 117
	8   GLEngine                            0x00007fffb4c05e02 gleUpdateDrawFramebufferState + 560
	9   GLEngine                            0x00007fffb4b164cb glSwap_Exec + 59
	10  OpenGL                              0x00007fffb4af8126 CGLFlushDrawable + 66
	11  gameoverlayrenderer.dylib           0x0000000101f4e702 _Z21SteamCGLFlushDrawableP17_CGLContextObject + 33
	12  KSP                                 0x0000000100f4737a _Z16PresentContextGL12ObjectHandleI19GraphicsContext_TagPvE + 90
	13  KSP                                 0x0000000100f62edf _ZN13GfxDeviceGLES12PresentFrameEv + 111
	14  KSP                                 0x00000001006b8282 _ZN15GfxDeviceWorker10RunCommandER20ThreadedStreamBuffer + 36242
	15  KSP                                 0x0000000100d9fccc GfxDeviceWorkerAutoreleasePoolProxy + 60
	16  KSP                                 0x00000001006b8fa4 _ZN15GfxDeviceWorker3RunEv + 116
	17  KSP                                 0x00000001006af44c _ZN15GfxDeviceWorker18RunGfxDeviceWorkerEPv + 60
	18  KSP                                 0x0000000100bee2ba _ZN6Thread16RunThreadWrapperEPv + 90
	19  libsystem_pthread.dylib             0x00007fffc572b93b _pthread_body + 180
	20  libsystem_pthread.dylib             0x00007fffc572b887 _pthread_body + 0
	21  libsystem_pthread.dylib             0x00007fffc572b08d thread_start + 13

Debug info from gdb:


=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

pid 61509 != 57908, skipping destruction (fork without exec?)

But I don't claim any significance (yet), as I dumbly didn't saved the Player.log from the VRAM crashings. I will revisit this next time it happens.

Edited May 14, 2018 by Lisias