Sorry. Sent this to the Cocoa list first by mistake. > On 2 Nov 2015, at 16:40, Fritz Anderson <[email protected]> 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 protected]> 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 protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/jonathan%40mugginsoft.com This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
