Re: Crash, but only in release version


John Brownie
 

Of course, as soon as I sent the message, I figured out a way to do the debugging, by setting the optimisation level for the debug version. So now I can see where the problem is, sort of.

It's weird. I unwrapped a bunch of macros and an inline function to get the various components visible in the debugger, and it works, but doesn't if I leave the macros and inline function there. Something strange in the optimiser, perhaps? I guess I'll leave the unwrapped version there since it works, and go from there.

John

Alex Zavatone via groups.io wrote on 20/4/20 14:46:

One thing I forgot is if you are debugging a release version (I expect that this is a Mac app), you may want to make sure that you are not stripping debug symbols.  

On Apr 20, 2020, at 6:44 AM, Alex Zavatone via groups.io <zav@...> wrote:

Report the properties of the URL beforehand.  At one case, I even had my old reporter get the properties, put them in a string and mail them to a specific email account to see what was going on.

You can also log to a specific file on disk and then open that up and tail it from the terminal to get only your specific output written to that file and updated instantly on screen right before the crash.



On Apr 20, 2020, at 6:22 AM, John Brownie <john_brownie@...> wrote:

I am getting a crash, but only in the release version. I get a very helpful "Error 1" if I try to debug the release version, and logging doesn't get me anything, as the crash prevents the log entry from appearing (I think).

Anyway, the crash is in CFURLCreateWithFileSystemPath, where it's calling length, and I get crash reports like the following:

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [40981]

VM Regions Near 0x3eaddd9f4338:
   MALLOC_LARGE_REUSABLE  0000000113885000-0000000114085000 [ 8192K] rw-/rwx SM=PRV
-->
   MALLOC_NANO            0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV

Application Specific Information:
objc_msgSend() selector name: length


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                   0x00007fff6e14381d objc_msgSend + 29
1   com.apple.CoreFoundation          0x00007fff3544dfb5 _CFURLCreateWithFileSystemPath + 67

The VM Regions list can vary a bit, but it's always the same stack trace and signal.

It looks a bit weird that a Core Foundation function is trying to call an Objective-C method. Ironically, this crash is triggered when I'm attempting to show the user an error message, and the upstream call is essentially a call to get a localized version of a string.

Any pointers on how to debug this? How to get the debugger to connect with the release version? Or how to work out what is different between the release and debug versions that might be forcing the error?

Thanks,
John
-- 
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland







--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland

Join cocoa@apple-dev.groups.io to automatically receive all group messages.