LLDB not able to debug application - iphone

I currently want to debug my application using the LLDB debugger. I am successfully able to run code in my application if I set a breakpoint on my iPhone app and when I click build and run. The problem is if I start my application without Xcode and attach the debugger to my iOS application. Doing it this way means I cannot debug my application.
When I do build and run from Xcode along with a breakpoint and run the LLDB command list. I can see that it is debugging the GameViewController.swift file, however when I attach the debugger to my app after running it normally, the LLDB debugger is now in the AppDelegate file.
How would I get the LLDB debugger to debug the file GameViewController.swift instead of AppDelegate,swift file?

Bear in mind that the debugger is attached to your entire application, not to a particular file.
When you attach to the program, it stops wherever the program happens to be; and if the program is idling, that will be in the AppDelegate more times than not.
To get it to list code in another file, you can use the list command, e.g. by using:
list GameViewController.swift:10
It lists the file GameViewController.swift, from line 10, for 10 lines.
You can add in a breakpoint for a method in GameViewController, e.g. for a method called onClick by doing:
breakpoint set --file GameViewController.swift -n onClick
or a line using:
breakpoint set --file GameViewController.swift -l 998
and then continuing, until it stops in the relevant piece of code.

Related

Run a code continuously in background in cocoa

I've been using Swift-Keylogger as a command-line program.
I thought of making a UI for it as I have started mac development recently.
As it is a command-line program, the author used RunLoop.current.run() in-order to run the keylogger continuously.
Now the problem is I can't use RunLoop.current.run() because it blocks the UI.
I have looked into GCD and it only runs a piece of code. But I want to run it continuously. I saw some additional articles about running continuously but I found running code continuously after every 'n' specified time by using Timer.
So, how can I replace the RunLoop.current.run() which has same behaviour without blocking UI?
UPDATE: 05/07/2018
To start and stop the keylogger from the UI, check this issue from GitHub
UPDATE: 18/01/2018
Some guy approached me with same requirement as yours. After some discussion and trial and error method, he found a solution.
1) Just comment out the RunLoop.main.run() line in the keylogger code.
2) Now disable the app sandbox. If you want to enable the app sandbox, then add this entitlement com.apple.security.device.usb = YES.
Original: 18/03/2017
I also searched for it a lot in the beginning when I'm writing my keylogger. After a day I gave up.
I use Process in swift to run the keylogger from my UI.
The way I do is:
Do the necessary modifications in keylogger source like the path of files/folders.
Compile the keylogger source.
Drag the keylogger to your project in your Xcode and check copy if needed.
The executable is in resources folder inside your .app.
Run the executable using Process class and launch() to start the executable/ your keylogger.
You should terminate the created process, otherwise the keylogger will be running in the background. To stop the keylogger, use terminate() on Process variable.
Code:
let pathToKeylogger = Bundle.main.resourcePath! + "/Keylogger" // path to keylogger executable
keylogger = Process() // You need to declare this variable at class-level because you need to have the variable later to terminate it.
keylogger.launchPath = pathToKeylogger
keylogger.launch()
To Terminate:
keylogger.terminate()
Edit: 18/03/2017
Try to quit your app normally i.e., either clicking quit in menu bar or in the dock instead of pressing stop button in Xcode. I think you are pressing stop in Xcode.

Breakpoint in section of Matlab

I have written a MATLAB code defined in different sections. After running the first section of my code I would like to be able to debug subsequent sections using breakpoints. For some reason, however, when I add a breakpoint and use the "Run Section" command the debug mode is not triggered. It appears that I'm unable to run the beginning of the program and then use a breakpoint and the "Run Section" command. Does anyone know how to do this? I'm doing this to save time since the beginning of my program takes a long time to run. Thanks.
There are a couple of work-arounds I can think of which might help you.
First, when you get to your breakpoint, save the entire workspace to a .mat file. Then comment out all the code up to this point and add a line to load your .mat file. You can now get to the point in your code you are debugging quickly.
Another way to do it would be to put all the code past your breakpoint in a separate script. Then when you hit the breakpoint, you can set more breakpoints in the second script and call it from the command window as many times as you need.

How do I set a symbolic breakpoint on _WebThreadLockFromAnyThread in Xcode?

I'm using Xcode 4.3.2 with lldb as my debugger.
I have inherited a project that contains code that is calling UIKit from secondary threads, as shown by these log messages:
2012-05-02 21:48:14.603 Appname Dev[77594:16e0f] void
_WebThreadLockFromAnyThread(bool), 0x8d5f810: Obtaining the web lock from a thread other than the main thread or the web thread. UIKit
should not be called from a secondary thread.
I have cleaned up most of the code that was making UIKit calls from secondary threads, but I am still occasionally seeing this message in the logs. The app is not crashing, so it's difficult to pinpoint where the problem lies.
I'd like to set a breakpoint on _WebThreadLockFromAnyThread, but when I try to set a symbolic breakpoint using:
b _WebThreadLockFromAnyThread
the debugger tells me:
breakpoint set --name '_WebThreadLockFromAnyThread' Breakpoint
created: 12: name = '_WebThreadLockFromAnyThread', locations = 0
(pending) WARNING: Unable to resolve breakpoint to any actual
locations.
I've also tried creating the symbolic breakpoint using the UI in the breakpoint navigator, but I'm not sure what to enter for the module. When I leave the module blank, the breakpoint is created but it's still not breaking when the log message appears in the debug console.
Can anyone tell me how I can go about adding a breakpoint on _WebThreadLockFromAnyThread, and also how I would determine what the defining module is for this symbol?
Just leave out the underscore. b WebThreadLockFromAnyThread works for me in both lldb and gdb. Now, this is Xcode 4.6, so if you're stuck on the older version I suppose it's possible that there's an issue in that version not present in 4.6.
You can try use nm command or class-dump tool to locate the module.
Most likely there are no symbols you need because xcode by default produces a "release" build which if I am correct strips the symbols making the exec file much smaller. I am not sure how at the moment but you need to find the option to switch to "debug" build which will guarantee to have all those lovely symbols waiting for your analysis.

How to know why application crashes in simulator

I'm running my application on the simulator but as soon as it starts it just closes I guess it crashes, however I dont get any error message or reason why it's crashing, I'm running it as debug also, is there anyplace or anyway to get an error message?
Try switching to "debugger" view, and look at the console from gdb, if it crashes you will see the error, and hopefuly the call stack.
Example of crash message: EXC_BAD_ACCESS.
If you don't have the call stack visible, you can try to type 'bt' (for back trace) at the gdb prompt.
A lot of times when my application randomly crashes before launching, there is a problem in an interface builder file (such as a connection to a now non-existant object). Check your interface builder files to see any potential bad connections or errors and if you can't find any, put an NSLog in your applicationDidFinishLaunching method to see if the application is actually being started before it crashes.
In Xcode, choose Run menu, then choose Debug — Breakpoints On. Xcode should now point you to the location in code where your app crashes in the Debugger view.

Xcode stops at breakpoints and seems to hang

I am trying to debug a small prototype for an iPhone App (iOS Simulator 4.1), compiled as Debug, with all the configuration apparently ok.
The application makes use of Cocos2d graphic engine and GDataXMLNode library (for XML reading). There isn’t much stuff going on. But on certain method, if I set a breakpoint, gdb simply “stops”.
Here’s the status line of the debugger after it hits he breakpoint:
And here’s the code that has the breakpoint(sshot):
note: the breakpoint could be anywhere in that function and it’s the same.
And this is the calling code (from another object)
self.map = [SimulationLoader loadMap];
None of the Editor buttons work when a breakpoint is set inside the “loadMap" (step into, step out, next, continue execution, etc.). I can stop and/or restart the debugging and it works (but goes back to the beginning). The gdb prompt, will let me write, but nothing happens. I cannot view object values or anything debugging related. I cannot resume execution, it won’t do anything.
The strange thing is that, if I put a breakpoint before or after that line (the loadMap), it all works, and I can step out or in, debug it and do all I want to do.
What am I missing?
A couple of seconds after the “failing” breakpoint is hit (and it “hangs”) the stack window clears. I believe all this happens because the gdb has stopped, but the question is, why does it stop there? What are the restrictions for this?
I’m compiling with LLVM GCC 4.2 for what is worth (but could probably change to other if that’s the problem, haven’t tried that because I don’t know much about the differences).
Is there something (maybe in your Map class?) that requires timing? For instance, a double-tap that's being interrupted by the breakpoint's being triggered at that spot?
(i.e., no breakpoint => double-tap registered, Breakpoint => second tap comes after breakpoint hits, so only a single-tap is registered.)
I don't see anything like this in your code specifically, but that's the kind of thing that could show mysteriously different behavior between breakpoints on/off.