Re: Crash running C code built on OS X El Capitan in Xcode 7
Re: Crash running C code built on OS X El Capitan in Xcode 7
- Subject: Re: Crash running C code built on OS X El Capitan in Xcode 7
- From: Jonathan Mitchell <email@hidden>
- Date: Mon, 02 Nov 2015 20:39:32 +0000
- X_v_e_cd: cb54b0ccbda7731436c42c391039b4be
- X_v_r_cd: 0f12c65400b0b4f6a989b67a605ba92f
> On 2 Nov 2015, at 16:40, Fritz Anderson <email@hidden> wrote:
>
> [Cross-ref the query “EXC_BAD_ACCESS puzzle when not running as test bundle” on cocoa-dev. The OP determined this was likely a tools issue, and has brought it here.]
>
>
> On 2 Nov 2015, at 8:27 AM, Jonathan Mitchell <email@hidden> wrote:
>>
>> The following C test code calls the current Mono 4.2.1-91 framework.
>> It builds and runs fine on Xcode 6.4 on 10.10.
>>
>> It fails if I build and run it on OS X 10.11 using Xcode 7.1 - EXC_BAD_ACCESS in mono_jit_runtime_invoke() when calling AssemblyName:GetName()
>> However the built binary runs fine outside of the Xcode environment.
>>
>> This obviously makes life difficult.
>> Any ideas or suggestions as to why this is occurring?
>> Is there anyway to mitigate it?
>
> Not being familiar with the Mono runtime (within which the crash occurs), I can’t offer anything specific. Maybe there’s a Mono list where you could find more-experienced help. You ask for mitigation; maybe I can offer ideas.
>
> 1. Systemic
>
> 1 a. Where is the Mono runtime installed, and therefore whence is it loaded? Is it different between Xcode and bare execution? It often is. [Cross-ref 3 b, below]
Mono is always loaded from /Library/Frameworks
>
> 1 b. Can you say, hand-to-God, that not one component of the runtimes comes from a different build?
Hand to whoever, wherever. This issue arose in Dubrovnik, my objc-Mono bridge. The code here is the issue distilled.
The test code links to a prebuilt Mono and CoreFoundation, period.
>
> 1 d. The location alone might uncover an issue with 10.11’s System Integrity Protection (rootlessness), though I’d think the bug/no-bug split would go the other way. This list could be of help from there.
>
> 1 e. A shortcut to determining whether SIP is the problem is to reboot from the recovery partition (hold R down when the startup gong sounds) and disable it.
I suspected SIP earlier and zapped it without effect.
>
>
> 2. Debugging
>
> 2 a. If you have the Mono runtime source, of course you’ve already set a breakpoint at the exception site and re-run so you could examine the frames in the call chain.
>
> 2 b. If you have the source but can’t get the debugger to show it to you (you should research ways to relieve that), you can audit the likely call chains to the crash site. Maybe you can trace the pointer — or its provenance — that went bad.
>
> 2 c. Of course you’ve already audited the pointer as it leaves your own code, and examined the values in the struct(s) it points to.
Needless to say the Mono code is one complex ball of C.
Looking in that haystack will be my last approach I think.
Objects look kosher as they leave my code.
I did try to use Xcode to inspect some objects along the call chain but with only mixed results.
>
> 2 d. Address sanitizer.
This option was disabled in the diagnostic settings for my C command line tool.
>
>
> 3. Alternatives
>
> 3 a. If it works standalone and fails in the Xcode testing harness, split the difference: Run the problem code under lldb from the command line. Find tutorials and explore the help text (practically the only current user documentation) before you start debugging, don’t try to learn and debug simultaneously.
>
> 3 b. The Xcode debugging wrapper will tell you where it found its dynamic libraries, but lldb can do it more explicitly.
>
> (Special case of the maxim never to learn a development tool with a gun to your head. I’ve been amazed at how people even do that _by choice._)
I hadn’t though of that. Thanks, will do.
I am rolling my dev environment back to 10.4 and will try and chase this down in a VM.
Thanks again.
Jonathan
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden