- Home /
How do I debug a crash in mscorlib.dll.s with Strip-assemblies turned on?
I started having a crash on startup when running our iOS title on target. The exception is an EXC_BAD _ACCESS error in mscorlib.dll.s in the following section of code:
Lm_198c: System_StringComparer_GetHashCode_object:
.byte 13,192,160,225,128,64,45,233,13,112,160,225,64,93,45,233,16,208,77,226,13,176,160,225,0,96,160,225,1,160,160,225
.byte 0,0,90,227,42,0,0,10,4,160,139,229,8,160,139,229,0,0,90,227,12,0,0,10,4,0,155,229,0,0,144,229
.byte 0,0,144,229,8,0,144,229,4,0,144,229,0,16,159,229,0,0,0,234
.long mono_aot_mscorlib_got - . + 68
.byte 1,16,159,231,1,0,80,225,1,0,0,10,0,0,160,227,8,0,139,229,8,0,155,229,0,0,139,229,8,0,155,229
.byte 0,0,80,227,7,0,0,26,10,0,160,225,0,0,90,227,25,0,0,11,0,16,154,229,15,224,160,225,40,240,145,229
.byte 0,96,160,225,7,0,0,234,6,0,160,225,0,16,155,229,0,0,86,227,16,0,0,11,0,32,150,229,15,224,160,225
.byte 76,240,146,229,0,96,160,225,6,0,160,225,16,208,139,226,64,13,189,232,8,112,157,229,0,160,157,232,6,0,160,227
.byte 58,12,128,226
In the line right after the '.long mono_aot_mscorlib_got - . + 68'
There is no meaningful callstack (the error is happening in Thread 1, and the only item in the stack is the 'System_StringComparer_GetHashCode_object' call that is crashing) and if I turn OFF code stripping entirely, the program starts up just fine.
I'm terrible at Xcode, but I'm fairly confident I'm using some library that's being stripped. I'm not sure how to debug the problem though, since it looks to me (by reading through the code) that I'm not doing anything incorrectly.
How do I go about figuring out what code is causing the error?
Answer by AntonStruyk · Aug 03, 2012 at 03:56 PM
So, I eventually discovered the problem was a combination of having Code-stripping enabled (any setting but 'disabled') the and the 'Script Debugging' build setting checked. When I disabled either of these (or both together), my build was totally playable.
In order to discover this, I had spent about a day slowly reverting my change back one line at a time until it crashed. Eventually I discovered that even adding a line of empty whitespace to the source file could make a difference between crashing on startup and working perfectly fine. Also, the error above wasn't the only one that I found during my experiments: sometimes it would crash with other errors, sometimes it wouldn't start at all, sometimes it would just close itself without any errors at all.
I suspect that the 'Script Debugging' feature inserts some code that ends up injecting a dependency on a stripped library, but that is entirely a theory and I have no evidence other than my experiments.