I've got 2 stations, one for development and another one for testing. I'd like to be able to run and debug targets that were built under release mode (the code is stripped) on the testing station.
Since the code may not be copied to the testing station for security reasons, I've tried remote debugging as described in the following link - http://lldb.llvm.org/remote.html.
Since both sides of the debugging runs OS X, the settings instructions specify that my local (development) station should run 'lldb-server' along with 'debugserver', and remote (testing) side should run 'platform'.
Unfortunately, I couldn't find all those tools inside the Xcode bundle. I also tried to download lldb source code and create those executable by myself, but I'm still missing the lldb-server target.
I wish I had some clear and comprehensive guide about how to do lldb remote debugging properly from A to Z.
Make sure that Xcode is installed on both machines. (Different versions are OK!)
On the remote machine (running the executable):
Start the app you want to debug
Start debugserver, attach to your app, and listen for connections from the other Mac:
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver development-mac.local:16000 --attach="Photo Booth"
On the development machine:
Start lldb by typing lldb
Connect to the debug server:
process connect connect://test-mac.local:16000
On the test machine, you should now see the message Waiting for debugger instructions for process 0. After a short while, the (lldb) prompt should appear on your development machine, and you can start debugging as normal.
Unfortunatly, I'm not sure how to connect from Xcode.
Please give feedback for Apple to update their documentation here
In the mean time, I'm getting more milage using hopperapp with app disassembly. http://hopperapp.com/ There's a free trial - and it has a remote debugger available.
Related
Question
My app has some bugs that only occur on older macOS versions. How can I debug them?
Approaches
Below are all of the approaches I'm aware of.
Approach 1: Debug using Xcode
The idea is to just use Xcode to build and debug the project on the older macOS version.
Unfortunately the latest version of Xcode that is available on the old macOS cannot open my .xcodeproj file.
I have come accross 2 possible solutions:
1.2 Change Project Format
I have set the Project Format to be compatible with a very old version of Xcode (8.0) but that didn't help.
2.2. Change manually edit project files
You can manually edit the project file with a text editor and decrease the objectVersion to get the project to open. See this SO Answer.
This worked for me.
To get the project to compile on the old macOS version, I had to do a few more hacks:
Set objectVersion to 46
Comment out all code that uses unavailable APIs
Set 'minimumToolsVersion' in Interface Builder files your Xcode version
Set the Code Signing Identity to "Ad Hoc Code Sign" and disable hardened runtime on all targets
After these steps I could build and debug my app on the old macOS version! Some things didn't compile properly, but luckily, in my case, this was good enough to figure out all of the bugs that were occuring on older macOS versions!
Update:
I just tried to do the same thing with a Swift project (The other one was ObjC only) and it was so much work that I almost gave up on it. See the bottom of this post for more info.
Approach 2: Debugging from the command-line
The second idea is to use the lldb debugger directly from the command line on the old macOS. This works fine. But the problem here is that it will only show me assembly code. To debug in an efficient way you want to be able to step through source code line by line. This is achievable but it's complicated:
The following data needs to be present on the old macOS:
The app/executable itself
The source code used to build that executable
Some sort of 'debug data' that links machine instructions in the executable to lines in the the source code
You need to tell lldb how to link that data together
Here's an article on how to do this: https://medium.com/#maxraskin/background-1b4b6a9c65be
This approach is very promising but I gave up on it for now because the setup and debugging workflow sounds very slow and tedious and Approach 3 seemed to be much easier. However I can't get Approach 3 to work at all so far. I'll update this once I look into it more.
Sidenote about 'debug data'
I don't really understand some things about the 'debug data' mentioned above.
From what I gathered, this debug data normally comes in the so called DWARF data format. Debuggers usually extract this DWARF data directly from .o files. .o files are a byproduct when compiling C code (and code in other languages too?).
However for storing and transferring the DWARF data to other machines you can also store it in so called .dSym files.
Now what confuses me is what role does 'code stripping' play in all of this? Because code stripping is described on the internet to "remove debug data from the exectable". My question is - what kind of debug data is in the binaries when you don't strip them? Is it the same DWARF data from the .dSym and .o files which can be used to step through code line by line in a debugger? Or is it a subset of the DWARF data? Or is it something completely different?
Either way here's approach 3:
Approach 3: Remote debugging from the command-line
The lldb debugger has the built-in capability to connect to another machine remotely, then automatically upload the executable you want to debug to the remote machine, and then run and debug that executable.
In theory, this should also let the debugger automatically locate the source code files and the DWARF data - allowing you to step through source code line by line without any extra effort.
This would make the approach much more convenient than Approach 2! So I gave it a try, using the official tutorial.
There are many things that aren't explained in the official tutorial, and it was very hard to Google the various problems I ran into. Here are some things that I had to do which are not mentioned in the tutorial:
I downloaded the latest Xcode and got the debugserver and lldb command-line-tools that are buried deep inside that app bundle. I ran debugserver on the remote machine and connected to it using lldb on the local machine.
The official tutorial talks about using the lldb-server command-line-tool instead of debugserver. But I couldn't find lldb-server in the latest Xcode app bundle nor the latest Xcode Command Line Tools. (The ones that show up at /Library/Developer/CommandLineTools after using xcode-select --install). Older Xcode versions still contained both lldb-server and debugserver and from my testing they behave the same. Only the command line arguments they take are a little different. So I used debugserver instead of lldb-server.
Then I had to open a wifi hotspot on the remote machine using the Create Network... option in the menu bar, and then connect the local machine to that wifi hotspot.
On the remote machine I started the debugserver with this command debugserver 0.0.0.0:1234. 0.0.0.0 means "accept connections from any IP address" and 1234 means only accept connections on port '1234'
On the local machine I started lldb and inside the command prompt I used the following commands:
platform select remote-macosx
platform connect connect://<remote ip address>:1234
Replacing <Remote ip address> with the IP address of the remote machine which you can find under System Preferences > Network.
1234 means 'connect on port 1234'
I don't know where the structure of this URL comes from. I found it by accident
After this, lldb on local and debugserver on remote will both say they connected successfully.
target create <path to appbundle>
Replacing <path to appbundle> with the appropriate path
After this, lldb looks like it's uploading the files to the remote machine, but debugserver on the remote machine won't react. Not sure if that's normal.
process launch
This should launch the app on the remote machine, but instead it just give this cryptic error: error: attach failed: invalid host:port specification: '[<Remote ip address>]'. (Where <Remote ip address> is the actual IP address of the remote machine).
I tested this many times on different macOS versions. Local was always Ventura 13.0 and remote was 10.14 or 10.13. Both lldb and debugserver had version lldb-1400.0.38.13.
I don't know what else to try to make remote debugging using lldb work.
Sidenote about 'GDB'
I haven't looked into using the classic gdb debugger yet. Should I? I heard it's less buggy than lldb and I assume my problems with remote debugging are due to bugs in lldb. If it worked as advertised, remote debugging should be by far the easiest way to solve my problem.
I'll update this if I learn more about using GDB for remote debugging.
I'll be very grateful for any tips or clarifications! I will also update this post if I find out more, so this can hopefully be a useful resource for anyone trying to debug a Mac app on an older macOS version.
Update/Conclusion
Approach 1.2 worked for me!
(Approach 1.2 is getting the project to build in an older Xcode by manually editing project files.)
If you want to further explore the other approaches I've come across, here are my thoughts on how they compare with Approach 1.
Comparison to Approach 2
(Approach 2 is debugging from the command-line)
Pros of Approach 1
Much nicer debugging workflow - You can use the Xcode GUI instead of the command-line, and you won't have to copy over 3 different files to a new machine every time you want to test a change to your code.
Pros of Approach 2
You don't rely on hacking the project files which might not work for all situations. E.g. this might introduce new bugs in your compilation target that interfere with the bugs you actually want to debug.
Comparison to Approach 3
(Approach 3 is remote debugging from the command-line.)
Approach 3 is the holy grail. The debugging workflow would be very nice, no manually transferring files between computers like Approach 2, no weird brittle hacks like Approach 1.
Sadly I couldn't get Approach 3 to to work after days of trying, so I've given up on it now. If you have tips on how to make it work please do let me know!
Update 2
Approach 1.2 worked for my orginal project which was ObjC only. I've now tried to apply it to a Swift project and it's so much more work.
I had to spend hours rewriting code which was written for Swift 5.6 to compile under Swift 5.1 - it did work in the end but it took hours.
Unfortunately I haven't found a way to get a newer Swift version to compile under the older macOS, so I had to resort to this.
So if you're using Swift in your project, Approach 1.2 might be too much work to be feasible.
Update 3
Another possible solution might be using a Virtual Machine but I can't find any examples for how to do this on the internet.
Before I started, I want to make it clear that the 'debugging' here I mean is for programming debugging, while not vagrant itself debugging.
We all know, Vagrant is great to maintain a solid devlopment evnrionment among a team, and also tons of benefits from it as stated all over Vagrantup.com.
My question is: For instance of python programming, how can I keep using my favorite debugging tools coming along with Pycharm on Windows, but the python dependencies are installed in the Vagrant virtual machines?
I can easily do the deployment and testing with Vagrant command line, but I still can not get the point of how to enhance the developing stage, especially debugging on the development machine (Windows here).
As you have quoted Python and PyCharm as the language and IDE, I will build on the same example. PyCharm supports a feature called Remote Debugging, but this is available only on the professional edition of pycharm. Pycharm has documentation on setting up of a remote debugger. I am quoting the answer from this SO Post. To consolidate the steps required
Upload & install remote debugging helper egg on the remote server that is to be debugged (vagrant machine)
Setup remote debug server run configuration: click on the drop-down run configuration menu, select Edit configurations, Click on the + button, choose Python remote debug.
set Local host name to your laptop's IP address, set port to any free port that you can use on your laptop (e.g. 8888)
Now follow the remaining instructions in that dialog box: copy-paste the import and pydevd.settrace(...) statements into your code, specifically where you want your code to "hit a breakpoint". This is basically the PyCharm equivalent of import pdb; pdb.set_trace(). Make sure the changed code is sync'ed to your server.
Hit the bug button (next to play; this starts the PyCharm debug server), and run your Python script just like you'd normally do, under whatever user, environment etc. When the breakpoint is hit, PyCharm should drop into debug mode.
I've tried to find an answer to this before posting this question. I've got a windows service running on another machine. I've written the service in C# and the directory from which the service executable runs holds both executable and debug files (.pdb). I'm attempting to remote debug the service for the first time using VS 2012 Remote debugging. I'm able to attach to the service process successfully. However, as this is my first time I'm not sure what I can do next. I've clicked the pause button and that pauses the service on the line ServiceBase.Run(ServicesToRun) which isnt much use to me. The service has a timer which sets off every 30 seconds and will run the code in the timer event.
My question is ... is there a way of stepping through the code using the debugger in such a scenario.
Do I need to have some debug specific code already in my codebase so that when a debugger attaches it will take me to a place in the code from where i can step through the code?
Thanks,
Andrew.
There are several ways to debug your developed remote application or windows service. If you were in your machine(local) that would be simple to debug.
System.Diagnostics.Debugger.Launch();
But as you are in different machine it depends how your both Machines are connected. Which means you have some limitations on debugging remote application/services.
A Quick search gave me the following result that seemed helpful to me for you,
You can use Remote Debugging Monitor that visual studio use for connecting to remote device and debugging. You can have a clear instruction here on How to: Run the Remote Debugging Monitor.
There's another tool which lets you debug remote application's after a proper setup. But it has some limitations or conditions that you must abide by.
Here is the tool named Remote Tool, you can find a detailed setup process from MSDN here on How to: Set Up Remote Debugging.
It has been clearly quoted there about the prerequisites for using this tool. But still I'm rephrasing those again for quick reviewers.
Prerequisites to use Remote Tool for Visual Studio
To debug on a remote device:
The remote device and the Visual Studio computer must be connected over a network or connected directly through an Ethernet cable. Debugging over the internet is not supported.
The remote device must be running the Remote Tools for Visual Studio 2012.
You must be an administrator to install the remote tools on the remote device. To communicate with the remote tools, you must have user access to the remote device.
Feel free to share if you get to a better and working solution.
Thanks for your response. It reminded me to post my solution here for others like me.
The solution is simple (It always is once you know it).
Ensure that you are running the same code on the target machine as you have open in Visual Studio. It has to be the same assembly and version else the debugger will not hit your breakpoints. Ensure you have your breakpoints setup where you want the debugger to break execution. Then attach to the target machine process and wait for the timer to kick in and run the process where you breakpoint is set.
Hope this helps.
Andrew.
I am trying to build and deploy a gaia build from git repo in Windows. I am trying to deploy it in অ Flame.
I am trying to do it in a windows 7 with cygwin installed. After installing everything this is the error I am getting
This works just fine in a Linux machine, but I need to do this in Windows since right now I have access to it only.
Any pointers to what I am doing wrong here?
I'm afraid it's not going to work without significant effort for several reasons. Much better to use a VM with Linux on as even if it did work it will be really slow. Windows is slow at handling lots of file access and Cygwin slows it down even more.
For example in making a simple change to config.sh (full stack build) so it works on Cygwin I found it took hours to run (on a decent PC). And then I had a couple of corrupt git repos I had to hand fix.
I also looked at getting gaia's make to work, but stopped after the problem just got bigger.
Here's what I found for future reference
The build is not really portable, it expects a linux like environment
While cygwin gives good linux emulation most of the tools run are win32 native and handling path conversion for them requires not trivial changes due to assumptions. For example you can switch to the Win32 XPCshell and hack the command line paths to use cygpath, but environment variable are an extra source of dependency in the JS scripts and are all unix paths. ( I did manage this part).
these path and environment dependencies get magnified with the C build chain and other tools.
You need to change the mount to use noacl or else cygwin attaches ACLs to simulate file properties, thus breaking things. It's might even be a little faster without ACLS
I also tried MinGW which provides native versions without the emulation so should be faster. However it falls short of the requirements and its automatic path conversion heuristics get in the way.
you need to turn of any antivirus prog as they slow it down. in fact the very first time I used the old FIrefox WIndows build it would crash after a long time. Turned out to be a mem leak in the AV :(
So all-in-all it's too much hassle in terms of dev time to convert and probably maintain. A true Windows build would be better but then it's so easy these days to run a VM. You can even share directories between the guest and host so could flash from Windows.
I also tried with cygwin, but was unable to build the gaia source code on windows.
It's not straightforward to build the gaia source code on windows. Please follow these steps:-
Download Mozilla Build from MozillaBuild - Mozilla Wiki and install the tools in c:/mozilla-build (preferred). It includes everything (make, wget, python etc) you need to build gaia source code.
Run start-shell.bat. If build process failed with this batch file then run start-shell-msvc2013.bat if you have Visual Studio 2013 or start-shell-msvc2015.bat if you have Visual Studio 2015. (You need Visual Studio for the second step).
Browse to the gaia source code directory using the command cd Mozilla/gaia.
Run DEVICE_DEBUG=1 make command. Don't run DEVICE=1 make or make command (because you won't be able to debug the apps, I was able to connect to the Firefox OS 2.2 but was not able to debug the apps when I ran these commands).
If you are running this command for the first time, it will download the b2g_sdk otherwise it will create a folder profile with your custom profile.
Open the WEBIDE using Firefox (Nightly preferred) and point to the profile folder you just created.
Links for your reference:-
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Developing_Gaia
https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Different_ways_to_run_Gaia
https://developer.mozilla.org/en-US/docs/Tools/WebIDE/Troubleshooting
https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Making_Gaia_code_changes
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites
I am trying to build a windows service that includes a Lua component, and links with Lua's shared libraries. I am building the code in Eclipse/CDT with MinGW. It builds fine, but when I run it, I get "Application failed to Initialize Properly (0x80000003). Click OK to terminate".
I am looking for clues as to what might be going on. A Hello World program compiles and runs fine, so there are no basic environment issues (I hope!). BTW, I am running on XP Home.
Update:
OK, I have figured out, by some guesswork, what was going on, and thought I'd post this for the benefit of others who might run into a similar problem - I think the lua DLL I was linking to, at runtime, was a different version than the one I built with. This caused the app initialization to fail I guess. When I made them to be the same file, things started working. I have not looked into why this would cause app init to fail, but I guess some symbol being at a different address or something? Or could it be that the DLLs were built with different tool chains?
This might be caused by not having permissions to access the DLLs required by the application. Are you logged in as an Administrator or member of the Administrator group?
Try logging in as Administrator to see if the problem goes away. This will help determine if it's a permissions issue, and then you can explore that further.
You could also try using the Dependency Walker (depends.exe) to see if this highlights any problems.
Cause of this problem is to try to run DOS programs, or 16-bit programs in Windows XP
To run DOS programs, or 16-bit environment in windows xp
To do so go to Start , Run and type gpedit.msc
And there go to:
User Configuration
Administrative Templates
Start Menu and Taskbar
And double-click on
Add "Run in Separate Memory Space" check box to Run dialog box
Select Enabled and then OK.
If the problem is not resolved, we will have to disable the Dr Watson , Do the following:
Go to the Start
Programs
Accessories
System Tools
System Information
Then go to:
Tools
Dr Watson
Or go to Start , Run and type drwtsn32
And disable:
Dump All Thread Contexts
And
Create Crash Dump File
And press:
OK
And then restart your computer .......
And then you will be able to run any game or program is running Dos or 16-bit, within Windows xp.