[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] 1 b. Can you say, hand-to-God, that not one component of the runtimes comes from a different build? 1 c. If there is a difference in the code, the path forward is clear, if tedious. 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. 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. 2 d. Address sanitizer. 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._) — F _______________________________________________ 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]
