I'm building a simple client-server application in C, and using Xcode as an IDE to develop it. It's my first time using Xcode for anything, so i'm a little green with the options.
I've created two targets, one for the client and one for the server. I can build and run either one just fine. However when I want to build and run both (IE execute client while server is running) the client build immediately disappears.
If i try to run two instances of the same target, say server and server, I will get a prompt as to whether I want to stop the original process or add the new process. I don't get the same prompt trying to run client while server is running.
The odd thing is when I set a breakpoint somewhere in the client source, the whole thing runs as expected. How can I get this to be the default behavior?
Thanks
I think the accepted answer is outdated. In Xcode 9, as long as you have two targets, one per app, you can select the first target and press 'run' to start that debugging session, and while that's running, change to the second target and press 'run' again and the second app will start.
In the debugger pane, you'll see a dropdown that lets you select which target you want to see the output from.
What I haven't yet found is how to automatically start them both from the same scheme. It's still a manual process, but it doesn't require multiple instances of Xcode or using the command-line.
The Xcode debugger can only be hooked to one application at one time.
In my own Client / Server debugging, what I usually do is either have two machines running Xcode, where one is testing with the Server and other is testing with the Client.
If you have only one machine, what I usually do is run an instance of the server or client from the command line (you can launch any app by going to the "Products" folder where the built products are kept, and then typing in "ProductName.app/Contents/MacOS/ProductName"; the application binary is kept inside the application's package) and then I run the Xcode debugger on the actual thing I'm targeting for debugging.
Hopefully this makes sense!
Related
We have a testing framework made in AutoIt for our Windows apps (older legacy apps that we will continue supporting). These have never been run on a schedule or part of CI (always been run manually). I tried to get some kind of auto run (or even just status reporting) out of the tests, with minimal luck.
I have a VM where the tests can run. I experimented with my own web app, which works okay locally for running and status reporting. But when set up on the server, AutoIt reports it cannot open the application. Same thing happens if I try to run the tests from a .bat file.
My current solution is to have AutoIt call my web app to report status (working okay locally, untested on the server), or to see if I can get AutoIt to report results back to TeamCity. I have the agent installed but when I run the build from TeamCity, AutoIt reports it can't launch the application. I tried this while logged into the VM, logged out, with RDS open; no luck.
Is it possible to run the tests manually from the VM and send results back to TeamCity? When I run them from TeamCity it reads the AutoIt output (which is in the expected format), but I need to let TeamCity know to update the results (so we can use TeamCity rather than my web app to show the results).
I may need to find a way to let TeamCity know a build has been started, which might then let it know to keep an eye on the process' output, but I'm not positive. Any ideas?
I solved this so it could be done more traditionally.
If anyone is confused by what "running the agent from the console" meant, it just means installing the agent without selecting the "as a service" checkbox, and then manually starting the agent by cd'ing to the BuildAgent/bin directory and running the command agent start. I also created a batch file that will do this automatically (but you must run it as admin).
Further, I found AutoIt couldn't do anything if the test doesn't run from the right directory, so I had to devise a solution to this.
The only issue now is that I have to have an old laptop always connected to the virtual machine the tests and app run on (since the AutoIt tests won't work without the VM desktop being interactive).
Not sure how clear the title is, but basically I've created a program for Windows which my company can use to build games remotely from their desktops. Currently the Windows aspect works without a hitch, but I'm struggling to get our Mac to build.
We use psexec for the Windows side, and I tried to use it for Mac as well (just hoping), to be stuck with an Invalid Handle error.
The way the program works is the user selects from their system tray what they want to build, we have two options that require the Mac, both of those currently are the only ones that don't work.
We do have the ability to remotely access the Mac as well, but we're looking to mostly automate the process so that literally anyone (even the non-technically savvy) can click two buttons and create a build.
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.
I tried searching, but did not find a specific post that could answer my question.
For my MacOS app, I have an external framework residing in /Library/Frameworks that I am linking to.
The app runs fine from Xcode. The app runs fine by itself on my dev system.
If I copy the app bundle over to another machine, and also copy over the external framework to /Library/Frameworks area (so it has a similar setup to my dev machine), the app crashes when it tries to perform the task that uses the external framework.
What's weird is that the app does not crash on the other machine if run from the terminal, or through gdb. It only crashes on the feature using the external framework when launched from the Finder. I made sure permissions etc are all open.
The crash is of BAD_ACCESS (SIGSEGV) type and the feature involves using the framework to write out a file.
Any thoughts about what could be causing the crash/how to go about debugging this?
Thanks
The most likely difference you're running into is working directories -- launching an application manually from the terminal will run it in whatever directory you happen to be in at the time, while launching it normally (e.g, by double-clicking it in the Finder) will start it up with a working directory of /. Make sure you aren't using any relative paths by mistake.
I have a setup project created by Visual Studio 2005, and consists of both a C# .NET 2.0 project and C++ MFC project, and the C++ run time. It works properly when run from the main console, but when run over a Terminal Server session on a Windows XP target, the install fails in the following way -
When the Setup.exe is invoked, it immediately crashes before the first welcome screen is displayed. When invoked over a physical console, the setup runs normally.
I figured I could go back to a lab machine to debug, but it runs fine on a lab machine over Terminal Server.
I see other descriptions of setup problems over Terminal Server sessions, but I don't see a definite solution. Both machines have a nearly identical configuration except that the one that is failing also has the GoToMyPC Host installed.
Has anyone else seen these problems, and how can I troubleshoot this?
Thanks,
I had LOTS of issues with developing installers (and software in general) for terminal server. I hate that damn thing.
Anyway, VS Setup Projects are just .msi files, and run using the Windows installer framework.
This will drop a log file when it errors out, they're called MSIc183.LOG (swap the c183 for some random numbers and letters), and they go in your logged-in-user account's temp directory.
The easiest way to find that is to type %TEMP% into the windows explorer address bar - once you're there have a look for these log files, they might give you a clue.
Note - Under terminal server, sometimes the logs don't go directly into %TEMP%, but under numbered subdirectories. If you can't find any MSIXYZ.LOG files in there, look for directories called 1, 2, and so on, and look in those.
If you find a log file, but can't get any clues from it, post it here. I've looked at more than I care to thing about, so I may be able to help
Before installing, drop to a command prompt and type
CHANGE USER /INSTALL
Then install your software. Once the install has completed, drop back to the command prompt and type:
CHANGE USER /EXECUTE
Alternatively, don't start the installation by a double click but instead go to Add/Remove Programs and select "install software" from there.
Good luck!