When attempting to remote debug IL2CPP iOS builds with MonoDevelop I get the error: "
Could not connect to the debugger." The error pops up almost instantly maybe a second or two after I try and connect to the iPad debugger. I’ve tried many things to get the script debugging to work, but the only way I can find is to switch “Scripting Backend” to “Mono (2.x)” in the build settings. Once it’s switched to mono, there is no problem and the debugger connects quickly without incident.
I checked the MonoDevelop log and it says the following when trying to connect to IL2CPP builds:
[usbmuxd] Start listen thread
[usbmuxd] Listen thread started
[usbmuxd] Send listen message
[usbmuxd] Attached: 1 ec6a9ab6737e712110b8f7b59a1750fb7dc4e794
[iproxy] Start proxy: ec6a9ab6737e712110b8f7b59a1750fb7dc4e794 12000->56000
[iproxy] Setup listen port
[iproxy] Setup listen port succeeded
[iproxy] Proxy thread started
[iproxy] Accept incoming connection
[iproxy] Got connection
[iproxy] Connect to device
[iproxy] Failed to connect to device: Connection refused
[iproxy] Accept incoming connection
ERROR [2015-08-25 10:37:29Z]: Error in debugger
Mono.Debugging.Soft.ConnectionException: Could not connect to the debugger. —> System.IO.IOException: DWP Handshake failed.
at Mono.Debugger.Soft.Connection.Connect () [0x000f9] in /home/builduser/buildslave/monodevelop/build/monodevelop/main/contrib/Mono.Debugger.Soft/Mono.Debugger.Soft/Connection.cs:1099
at Mono.Debugger.Soft.VirtualMachine.connect () [0x00000] in /home/builduser/buildslave/monodevelop/build/monodevelop/main/contrib/Mono.Debugger.Soft/Mono.Debugger.Soft/VirtualMachine.cs:329
at Mono.Debugger.Soft.VirtualMachineManager.Connect (Mono.Debugger.Soft.Connection transport, System.IO.StreamReader standardOutput, System.IO.StreamReader standardError) [0x00022] in /home/builduser/buildslave/monodevelop/build/monodevelop/main/contrib/Mono.Debugger.Soft/Mono.Debugger.Soft/VirtualMachineManager.cs:334
at Mono.Debugger.Soft.VirtualMachineManager.ConnectInternal (System.Net.Sockets.Socket dbg_sock, System.Net.Sockets.Socket con_sock, System.Net.IPEndPoint dbg_ep, System.Net.IPEndPoint con_ep) [0x00075] in /home/builduser/buildslave/monodevelop/build/monodevelop/main/contrib/Mono.Debugger.Soft/Mono.Debugger.Soft/VirtualMachineManager.cs:287
— End of inner exception stack trace —
[iproxy] Stop proxy: 12000
[iproxy] Proxy thread exiting
I’ve attached my build settings to this post as well. Is there something I’m doing wrong here? Is there some setting that I should turn on/off?
No, there is nothing wrong on your end. We don’t support managed code debugging with IL2CPP yet. We have a alpha quality version of it internally, but it is not ready to be released. We are however looking getting this working.
In the meantime, you can debug the C++ code generated by IL2CPP in Xcode. The debugging experience is not nearly as good as debugging managed code, but it is better than nothing. You can find some details here:
No, unfortunately I don’t have a timeline yet. This is on our internal roadmap, but we’re not ready to schedule it in a release yet. When we do, it will show up on the Unity public roadmap: https://unity3d.com/unity/roadmap
Ok, unless there’s some other technique for gathering crash data on beta devices I’m not aware of I’d be surprised if this isn’t a massive priority for most developers with live apps.
We used to be able to script debug, send out to 30-40 beta testers, track and fix exceptions immediately with traces down to the line number in managed code. I’ve just spent three days straight trying to track down the cause of an exception logged from live il2cpp code, I have no idea if it’s the signature for multiple causes, where they’re coming from, no clues at all other than the trace started at Unity’s Update or FixedUpdate loop and ended in an unhanded exception.
We don’t seem able to trigger the issue/s in editor nor when moving back to the MONO compiler - in any case I wouldn’t be comfortable testing and declaring problems fixed on a different compiler to the one we’re shipping with.
Do you know any better approach to debugging such a problem @JoshPeterson ?
I’m curious about what is different between Mono and IL2CPP in this regard, specifically with respect to managed stack traces. Previously with the Mono scripting backend, where did you see the managed stack traces?
Currently Il2CPP does not provide source code line numbers for managed stack traces, but it should be able to still generate useful stack traces with method names.
But again, if you didn’t need to do any of this with the Mono scripting backend, it is probably better to track down the difference with IL2CPP so that we can make IL2CPP work similar to Mono in this regard.
We were using HockeyApp with script debugging enabled and it would debug with native methods and often line numbers in the trace with Mono2.x compiled builds.
This C# hook looks like a solution, I just tried hooking into it and logging properties from a forced exception and it’s telling me the managed script and method name. Booyah! Hopefully this will tell us about the gameplay crashes related to the the trace above, will need to rig up a system to log remotely. Thanks for the tip, this looks like it might help.
No idea why HockeyApp isn’t utilising this and collecting more meaningful data then, maybe they used to intercept exceptions at a different point when ‘script debugging’ was available. I’ll email their support and note here for anyone interested.
Thanks for the information. I wonder if HockeyApp was catching signals to handle crashes. If so, we may need to work with them to get things working better with IL2CPP (as it does not use signals). Please post here if/when you hear back from them.
@JoshPeterson yeah with IL2CPP Hockey doesn’t seem to give any useful information about the source of null reference exceptions, which in my experience is the vast majority of exceptions. We tend to switch back to Mono build a lot for fast build time in testing cycles anyway but I wonder if there aren’t others getting quite stuck with debugging that haven’t figured out / don’t want to / are unable to do this.
In any case the only way to debug a published / live IL2CPP build exhibiting problems would be to:
a) Receive notice of a crash in the build
b) Push out a Mono compiled version of the build to testers (assuming NO changes have been made since launch to guarantee testing identical code-base and peace of mind - highly unlikely)
c) Wait / hope for someone to trigger a crash
d) Fix the crash and try to convince ourselves that it was the one occurring in the live build
Perhaps there’s something I’m doing wrong with setup but I think that’s where it’s at. Would be awesome if you do have the ability to help Hockey-app work with the new compiler.
For now we successfully made a system to catch exceptions using the method you suggested and log them to our Parse server on next game load. Still a bit of deduction needed as it resolves down to the originating method name but in most cases can find the issue in seconds and with relative certainty that we’ve fixed the correct bug. =)
This workflow for tracking down crashes seems like far too much hassle (as I’m sure you’ve seen). We really should make HockeyApp work with IL2CPP. Can you put together a sample project showing how to integrate with HockeyApp and submit a bug report? That is probably our best route to solving this issue.
@JoshPeterson , is this feature still not supported? I am unable to debug any IL2CPP project. Any deadlines already? I believe this is a “must” feature that has been delayed too much…
We don’t have any support for a managed debugger with IL2CPP ready to release yet. Your best option is still to debug the generated C++ code, as mentioned earlier in this thread. We don’t have a deadline yet for supporting a managed debugger. We would like do so, but it is a matter of a lack of development resources from our side at the moment. We’re working on higher priority items.
I don’t see a feature request yet for this on feedback.unity3d.com. Can you add one?
