Use lldb to debug native libraries with Xamarin - ios

The Xamarin debugging documentation indicates:
Use Xamarin Studio's native debugging support for debugging C# and
other managed languages code and use LLDB when you need to debug C,
C++ or Objective C codethat you might be linking with your Xamarin.iOS
project.
However I cannot find any documentation on how to use LLDB to debug a Xamarin app. If I run my app in the iPhone Simulator and try to attach to it using LLDB I get the following error:
(lldb) attach --pid 37993
Process 37993 exited with status = -1 (0xffffffff) lost connection
error: attach failed: lost connection
Attaching using Xcode doesn't work either. I tried different variations of attach but none of them worked.
Can someone point me in the correct direction on how to debug Xamarin apps with LLDB? Moreover is this something I could do on the device and not just in the simulator? I didn't find any information on how to use LLDB to attach to a process on a device.
Update
It looks like the debugserver process is crashing whenever I use lldb to connect to my binary. Here is a link to the crash report for debugserver:
https://www.dropbox.com/s/9lizhl2quj9n0cc/debugserver_2015-07-07-131423_gauss.crash?dl=0
Update 2
When I run dtruss on the app it prints the system calls till it encounters
dtrace: error on enabled probe ID 2475 (ID 194: syscall::ptrace:return): invalid user access in action #5 at DIF offset 0
which happens when something calls ptrace(PT_DENY_ATTACH, 0, 0, 0); Why is PT_DENY_ATTACH called?
Update 3
I traced the ptrace system call to this function: mono_assembly_init_with_opt which happens very early in the life of the program. All that function does is call ptrace, so if I just return early from that function, I can debug with lldb.
Basically, I can do:
(lldb) process attach --name AppName --waitfor
# when the process starts
(lldb) b mono_assembly_init_with_opt
(lldb) c
# when the thread breaks
(lldb) thread return 0
(lldb) c
and now I can happily debug with lldb.
But, I shouldn't have to do this. Is there something wrong with my project config (I can debug simpler apps with lldb) or is Xamarin being evil?

Codesigned apps on Mac OS X can only be debugged if they have a particular attribute set in their app plist. You want something that looks like:
<key>SecTaskAccess</key>
<array>
<string>allowed</string>
<string>debug</string>
</array>
You can look at the man page for taskgated for a somewhat terse description of this process.
Usually for Xcode projects, this attribute gets consed up and inserted into your debug builds by Xcode, so you don't need to do anything to get this to happen.
I don't know how Xamarin works, but it is possible that it is not setting this attribute. On older OS X systems, root can debug anything, so you could try sudo -s and then debugging from there. But starting with Yosemite, the request not to be debugged is being more broadly honored...

Have you tried using the pid from the Activity Monitor? Just type your app name into the search box in Activity Monitor when running it in Debug.
If it still doesnt work can you try just creating a new project and attaching to that just to rule out any project config.

This happens to be a limitation imposed by Xamarin in the trial version. After upgrading to a paid license, this is no longer an issue. Even though Xamarin's website says:
When you begin a Xamarin Trial, you get access to the full Xamarin
Business feature set for 30 days.
It's clearly not the full feature set since they explicitly disable attaching lldb to the app if you are using a native library. I'm not sure the reason for doing so, maybe someone from Xamarin can comment on it.
Explanation
Thanks to Jim Ingham for pointing me in the right direction. The way Xamarin events debuggers from attaching to the app is by calling ptrace with PT_DENY_ATTACH. This system call enables the process to deny requests for debugging. (Detailed Explanation).
Moreover rather than calling the ptrace function directly, Xamarin tries to hide the call by using the syscall method (link).
Workaround
If you really need to debug your app and are still using the trial version, here is a workaround. The ptrace system call is made in the function mono_assembly_init_with_opt which happens very early in the life of the program. That function doesn't do anything else and can be skipped. Since the function is called right in the beginning of the process, we need to attach lldb before the function is called.
The steps are as follows:
Start lldb and wait for the app to start.
When the app starts, add a break point for mono_assembly_init_with_opt
Resume the app and when it stops at that function, return early without executing that function.
After this you can use lldb or attach Xcode to the app and debug your native code as usual.
Steps in lldb:
(lldb) process attach --name AppName --waitfor
(lldb) b mono_assembly_init_with_opt
(lldb) c
# when the thread breaks
(lldb) thread return 0
(lldb) c

Related

Swift keyboard extension SIGQUIT, Execution was interrupted, reason: EXC_BREAKPOINT

When I try to build and run my keyboard extension, it sometimes just crashes with a Thread 1: signal SIGQUIT.
I am not able to reproduce the error. Sometimes I can build and run my app but most of the time the keyboard just quits. This happens on an actual device. In the simulator it does not open my keyboard and says Waiting to Attach.
The console does not output any errors at first. However, if I change the dropdown to View UI Hierachy in the Debug navigator I get the following description:
Details: No plist data for fetching view hierarchy: error evaluating expression “(id)[(Class)objc_getClass("DBGViewDebuggerSupport_iOS") fetchViewHierarchyWithOptions:(id)[(Class)objc_getClass("NSDictionary") dictionaryWithObjects:(id)[(id)[(id)[(Class)objc_getClass("NSArray") arrayWithObject:(id)[(Class)objc_getClass("NSNumber") numberWithBool:1]] arrayByAddingObject:(id)[(id)[(Class)objc_getClass("NSArray") arrayWithObject:#"_UIVisualEffectBackdropView"] arrayByAddingObject:#"_UIBackdropEffectView"]] arrayByAddingObject:(id)[(Class)objc_getClass("NSNumber") numberWithBool:0]] forKeys:(id)[(id)[(id)[(Class)objc_getClass("NSArray") arrayWithObject:#"DBGViewDebuggerUseLayersAsSnapshots"] arrayByAddingObject:#"DBGViewDebuggerEffectViewsToSnapshotAsImage"] arrayByAddingObject:#"DBGViewDebuggerAlwaysEncodeLayers"]]]”: error: Execution was interrupted, reason: EXC_BREAKPOINT (code=1, subcode=0x18daddc34).
The process has been returned to the state before expression evaluation.
Method: -[DBGAbstractViewDescriber handleFetchedViewInfo:fetchError:resultHandler:]
Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide.
I also took a screenshot of the processes.
Am I doing something wrong and how could I prevent that my keyboard extension quits all the time when running it? Is it actually a bug as it says in the description?
DISCLAIMER
It seems like something in xCode 8.2.1 is broken and the debugger is not correctly attaching to the correct process or the hosting process is not properly loading the new code.
This is a not a permanent solution but a temporary workaround.
WORKAROUND
I have been able to work around this issue by following the steps below.
Kill any process that is using your keyboard (important!)
Launch the application using the debugger so the latest code is deployed to the device
Navigate to Settings > General > Keyboards > etc.
Remove your custom keyboard
Re-add your custom keyboard
Debug the application once again
The reason this works is because removing the keyboard kills the process that is hosting the extension allowing Xcode to attach to the new binary.
As I understand this is a bug in Xcode 8.2.1. because before update my custom keyboard was working very well.
this is a temporary solution.
Run your code like always!
Bring up your keyboard until the error (SIGQUIT) appear!
Goto xcode > debug > detach
Goto again Xcode > debug > Attach to Process: attach the keyboard (it should be first process)
now, your breakpoints will work. but there are no log output unfortunately! I hope it temporary solve your problem

NSLog not showing in handleWatchKitExtensionRequest, but breakpoints works [duplicate]

I'm just getting started with Apple Watch. I found instructions from "Five Minute Watchkit", on getting the iOS app and the watch kit app both running in the simulator and both processes attached to the LLDB debugger.
What I do is launch and quit the iOS app to install a current version in the sim. Then I switch to the watchKit scheme and launch that, which displays my watch app UI on the watch simulator.
I then launch the corresponding iOS app in the simulator, then user "attach to process" in the Xcode menu to attach the debugger to the running iOS app.
This works. I can set breakpoints in either the watch kit InterfaceController or in my iOS app and the debugger breaks there when it should.
However, I'm not seeing NSLog() statements in the debug console from my iOS app. (I do see log statements from the WatchKit extension code.) If I set a breakpoint in my iOS app, it does stop at that breakpoint when it should. I assume the lack of console output from NSLog has SOMETHING to do with attaching to a running process on the sim rather than launching it from Xcode, but I don't know what that something is.
(BTW, attaching an action to a breakpoint that invokes NSLog from the breakpoint also doesn't display, but the "log message" debugger command DOES display.
Does anybody have any insights?)
EDIT:
The code in the iOS app doesn't seem to matter. In my case, it was a dirt simple IBAction that was attached to a button in the iOS app storyboard:
- (IBAction)buttonAction:(UIButton *)sender;
{
NSLog(#"Button clicked on iPhone");
}
I can set a breakpoint on that NSLog statement. The debugger stops at that line, but I don't see the log statement in the debug console.
I can reproduce that with a simple test app, sans WatchKit. The app consists of a NSTimer that prints "Timer fired" every second. (This code is 100% correct ;). Nothing shows in the log after I have manually attached to the process.
As far as I know NSLog outputs to stderr, I guess attaching the debugger does not redirect stderr to the Xcode terminal.
If you are okay with using the console app or the terminal to look at your logs you can do that. iOS8 stores simulator logs in ~/Library/Logs/CoreSimulator/<Device-UUID>. In this directory you will find a system.log, which contains all your NSLog output.
You can look at it in terminal (cat, grep, tail), or open it in the Console.app.
Apple confirms that (at least for GDB) in Technical Note TN2239: iOS Debugging Magic.
Console Output
Many programs, and indeed many system frameworks, print debugging
messages to stderr. The destination for this output is ultimately
controlled by the program: it can redirect stderr to whatever
destination it chooses. However, in most cases a program does not
redirect stderr, so the output goes to the default destination
inherited by the program from its launch environment. This is
typically one of the following:
If you launch a GUI application as it would be launched by a normal
user, the system redirects any messages printed on stderr to the
system log. You can view these messages using the techniques described
earlier.
If you run a program from within Xcode, you can see its
stderr output in Xcode's debugger Console window (choose the Console
menu item from the Run menu to see this window).
Attaching to a
running program (using Xcode's Attach to Process menu, or the attach
command in GDB) does not automatically connect the program's stderr to
your GDB window. You can do this from within GDB using the trick
described in the "Seeing stdout and stderr After Attaching" section of
Technical Note TN2030, 'GDB for MacsBug Veterans'.
The mentioned TN2030 is no longer available on their server (mirror). It showed how you can redirect stdout and stderr to the Xcode console. However, since shell tty isn't a valid command for LLDB it won't help much. But maybe there is a different way to access the tty Xcodes console uses, so I attach the important part of that TN.
Seeing stdout and stderr After Attaching
If you attach GDB to a process (as opposed to starting the process
from within GDB), you won't be able to see anything that the process
prints to stdout or stderr. Programs launched by the Finder typically
have stdout and stderr connected to "/dev/console", so the information
they print goes to the console. You can view this by launching the
Console application (in the Utilities folder), however, it's
inconvenient to have to look in a separate window. Another alternative
is to connect the process's stdout or stderr to the terminal device
for GDB's Terminal window. Listing 9 shows how to do this.
Listing 9. Connecting stdout and stderr to GDB's terminal device.
(gdb) attach 795
[... output omitted ...]
(gdb) call (void) DebugPrintMenuList()
No output )-:
Close the stdout and stderr file descriptors.
(gdb) call (void) close(1)
(gdb) call (void) close(2)
Determine the name of the terminal device for GDB itself.
(gdb) shell tty
/dev/ttyp1
Reopen stdout and stderr, but connected to GDB's terminal.
The function results should be 1 and 2; if not, something
is horribly wrong.
(gdb) call (int) open("/dev/ttyp1", 2, 0)
$1 = 1
(gdb) call (int) open("/dev/ttyp1", 2, 0)
$2 = 2
Try the DebugPrintMenuList again.
(gdb) call (void) DebugPrintMenuList()
Yay output!
Index MenuRef ID Title
----- ---------- ---- -----
<regular menus>
00001 0x767725D3 -21629 Ed
00002 0x76772627 1128 <Apple>
00003 0x767726CF 1129 File
00004 0x76772567 1130 Edit
[... remaining output omitted ...]
To add onto Filipp Keks answer, here's a visual representation of a much much simpler way to do it than the accepted answer.
From Filipp Keks's answer:
Plug in the device and open Xcode
Choose Window -> Devices from the menu bar
Under the DEVICES section in the left column, choose the device
To see the device console, click the up-triangle at the bottom left of the right hand panel
Click the down arrow on the bottom right to save the console as a file"
This screenshot was taken in Xcode 7.3.1 of the Devices window.
With Xcode Version 7.2 and iOS 9.2 etc, I found the following works:
Kill both the phone app and watch apps
Select the Watch Extension Target and hit Cmd+R (build and run)
Select the Phone target and hit Ctrl+Cmd+R (Run without building)
In my case, I have both apps up in their simulators and get NSLog output for both. I don't need to attach separately. Hope this helps.
https://developer.apple.com/library/ios/qa/qa1747/_index.html
Plug in the device and open Xcode
Choose Window -> Devices from the menu bar
Under the DEVICES section in the left column, choose the device
To see the device console, click the up-triangle at the bottom left of the right hand panel
Click the down arrow on the bottom right to save the console as a file
When your Provisioning profile is set to AdHoc or Distribution then Xcode doesnot show log, you need set development to view log
This might not solve showing up NSLog messages, but it might be helpful when debugging app started in background.
You can use the breakpoint feature that allows you to log messages.
The idea is to:
Create a breakpoint with "Automatically continue after evaluating actions" checked
add "Log message" action (you can also use expressions and print out values, for example: "Log message #variable#")
Attach debugger using anticipated process name (XCode will wait for the process to start)
Trigger app start.
Credits and details:
https://fluffy.es/how-to-debug-app-which-got-launched-push-notification/
In my case a set Automatically to see NSLog, before don't show at all
I came to this question, via this one (Xcode console empty after attaching to process) which is now closed.
My issue is that the debug console in Xcode is showing nothing (just an empty white box).
The solution for me is a tiny toggle at the bottom which changes between "variable view" and the actual debug console.

Xcode+watchkit simulation: does not support a debuggable architecture:

I am trying to run in Xcode both the main App (which is active in background) and the WatchkitApp (which sends requests to main App through the watchkit extension). Everything works fine in standalone, but no way to make it work simultaneously.
My main concern is to understand this message when trying to attach a process: what does this mean ?
Xcode couldn't attach to "myApp"
"myApp" does not support a debuggable architecture
Thank you.
Edit:
I just read that main app in ObjectiveC and watch app in swift is a problem: https://mkswap.net/m/blog/How+to+debug+an+iOS+app+while+the+WatchKit+app+is+currently+running+in+the+simulator
It happened to me when an extension process was hanging around refusing to terminate. Find and kill it in the Activity Monitor.
Actually, I had that same error message, and I fixed it by resolving a bug that crashed my phone app on launch.
I didn't think to run just the phone in debug so I got confused too.
I'm running ObjC on the phone and Swift on the Watch App.

Windows phone 8.1 app crash. How can I see the exception?

I have an application in Windows Phone 8.1. I debug it in an actual device and it works ok. However, when I run the app outside the visual studio, sometimes (random) it crashes.
Is there any way to see if there is an exception? In Android and iOS you can see the log although application is not running on Debug.
I think maybe it could be a memory problem, I load a lot of data. How can I check if this is the problem?
Thank you very much
There is no automatic logging for you, but you can use the global exception event:
Application.Current.UnhandledException += ...
There you can get your exception: Put it in a log file, just show a message dialog, etc.
I found a solution, where I was getting not enough quota is available to process this command windows phone 8.1
Windows phone 8.1 have bug for navigate frame.
I replaced :
Frame.Navigate(typeof(SecondXAML));
To :
await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => Frame.Navigate(typeof(SecondXAML)));
guys now no above exception. not enough quota is available to process this command windows phone 8.1
Tested 100 times calling. not crashing.

The program 'Mono' has exited with code 0 (0x0) when debugging iOS from VS

I have a problem that when I try to debug my iOS app with VS2013 (with Xamarin) I get the following error:
The program 'Mono' has exited with code 0 (0x0).
I am aware of the following answer. Cleaning the solution does solve the problem but then the next time I debug I need to do it again...
Would really appreciate if someone has a long term solution.
Is it crashing during launch? You've only got 10 seconds to launch and complete the FinishLaunching method in the AppDelegate, otherwise iOS terminates the app. This restriction doesn't apply in the simulator. If you've got a breakpoint in code that is running in this 10 second window, there's a very high likelihood that the app will be terminated unless you're very quick to continue.
I've also found that having breakpoints set anywhere in the app can add a few seconds to the launch time while the debugger hooks everything up. If your app is big or uses a framework like MvvmCross (which can take several seconds to initialise), you can be in a position where every millisecond helps.
If you can, let the app launch, then set any breakpoints. But if you're trying to debug your startup code, that's far from easy.
If you are using the Visual Studio Android Emulator: have you tried check "Migrate to a physical computer with a different processor version" in Hyper-V?
I got this trick from here Fix for Could Not Connect To Debugger

Resources