Re: Debugging Privileged Helper Tool


Mark Allan
 

In case anyone's interested, I resolved the issue a couple of days ago (I've been testing ever since, just to make sure.)

Instead of trying to debug the privileged helper tool (which appears to be all-but impossible), I attacked the problem from a different angle. I copied the class responsible into my main app and called it directly from there. After a few minutes in the debugger, I spotted the problem and fixed it.

FWIW, the root cause of the crash wasn't over-aggressive optimisation by the compiler, it was premature optimisation caused by me. I have a string variable whose value changes rapidly during app execution, so I thought I could save a few processor cycles by directly accessing the iVar instead of using the objective-c accessors. In hindsight, of course that's going to blow up at some point!

Changing the value to a property (atomic, strong) and using the appropriate accessors resolved the issue. It may be marginally less efficient, but it doesn't crash, so I'm happy with that for now.

Thanks for all the suggestions.
Mark

On 11 Nov 2017, at 10:02 pm, Mark Allan <markjallan@gmail.com> wrote:

Yeah given the mention of malloc in the stack trace, I thought that too, but memory usage in the helper stays constant at around 2.5MB. This is also the only crashlog that mentions malloc. The rest are all some variation on objects being over-released or released prematurely.

Application Specific Information:
objc_msgSend() selector name: isKindOfClass:

Thread 1 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libobjc.A.dylib 0x00007fff5763ee9d objc_msgSend + 29
1 com.apple.Foundation 0x00007fff32d9f22d -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2130
2 com.apple.Foundation 0x00007fff32d9e7e9 -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:] + 125
3 com.apple.Foundation 0x00007fff32dad997 _NSXPCDistantObjectSimpleMessageSend2 + 46


On 10 Nov 2017, at 9:49 pm, Jack Brindle <jackbrindle@me.com> wrote:

That doesn’t look like an optimization issue, more like a lack of memory when the library goes to allocate memory for a new object.
XPC just seems to be triggering the object allocation. Is that side memory-limited or have some other constraints? Or is there a
leak causing it to run out of memory?

Debugging problem in code run by root (usually daemons) is much harder since Apple stopped us from logging in as root…
I’d bet there is a way to override that, though.

- Jack


On Nov 10, 2017, at 6:23 AM, Mark Allan <markjallan@gmail.com> wrote:

Hmm. I spoke too soon.

Even with -O3 and -O2, it still crashes. The backtrace shows the same line of my own code, but a different location within the macOS code.

Thread 2 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libsystem_malloc.dylib 0x00007fff583e5318 tiny_malloc_from_free_list + 323
1 libsystem_malloc.dylib 0x00007fff583e4403 szone_malloc_should_clear + 422
2 libsystem_malloc.dylib 0x00007fff583e5cc0 malloc_zone_calloc + 87
3 libsystem_malloc.dylib 0x00007fff583e65d6 calloc + 30
4 libobjc.A.dylib 0x00007fff5763ecea class_createInstance + 87
5 libdispatch.dylib 0x00007fff58202baa _os_object_alloc_realized + 35
6 libxpc.dylib 0x00007fff584fab0d xpc_dictionary_create + 37
7 com.apple.Foundation 0x00007fff32d9ea82 -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 167
8 com.apple.Foundation 0x00007fff32d9e7e9 -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:] + 125
9 com.apple.Foundation 0x00007fff32dad997 _NSXPCDistantObjectSimpleMessageSend2 + 46
10 com.myapp.mytool.HelperTool 0x00000001055b3ad7 -[HelperTool updateProgressWithMessage:forRun:] + 119 (HelperTool.m:501)
This happens after running for around an hour or so. I'm trying again now with "Fast [-O, O1]"...

Mark

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