I've created a small daemon which allows me to control my external display's brightness via DDC. The thing is, after it's been running for ~30 mins or so, it inexplicably closes.
My main.swift is very straightforward:
import Foundation
let application = NSApplication.shared
let applicationDelegate = AppDelegate()
application.delegate = applicationDelegate
application.activate(ignoringOtherApps: true)
application.run()
The strange thing is, it seems to exit with exit code 0, and when in the debugger Xcode says it ended normally. Yet if I print something after application.run() or add a breakpoint there, it never seems to fire.
I've tried adding various symbolic breakpoints to exit, but it never manages to catch where it's happening, and I've got no calls to exit in the codebase anyway.
Why might my application be closing by itself? What can I do to work out the cause?
Related
I'm creating an app using WinUI3 (UNO actually, but I don't think this is relevant) to babysit an application written in 2007 that I have no control over. I'm starting it like this:
try
{
using var process = Process.Start("child.exe");
await process.WaitForExitAsync();
//...do some processing here
}
catch (Exception)
{
throw; //only here so that I can set a breakpoint to debug this issue
}
Peculiarly, when the child.exe exits it takes down the parent app with it. This is not the default behavior since starting other programs the same way do not do this. Things I have already looked into:
The catch block never catches anything. The same thing happens even if I comment out the await line and everything after.
Breakpoints after the try block are not hit. Visual Studio debugger simply detaches from the parent app.
Event Viewer does not log any error events related to this.
Attaching spy++ to the parent app shows that WM_Close isn't being sent to it. In fact, the moment the child terminates spy++ logs no more messages from the parent at all. (If I close the parent app normally then spy++ does log window messages associated with closing)
Overriding App.Closed event and setting WindowEventArgs.Handled = true does not prevent the parent from dying. (The close button is disabled as expected, so the event is working fine)
At this point I'm pretty sure the child.exe is actively doing something to kill the parent, although running the program directly doesn't seem to do the same thing to explorer. While I'm curious about what it could be doing to cause this, I'm more interested in ways to prevent my parent app from dying.
I'm trying to debug a Terminal app upon launch, so I've created a new scheme and selected:
I build my app, then I go to Terminal and run the app. Immediately, instead of hitting a breakpoint, I get:
And in my terminal the app is run and exited normally, without debugger attached:
My breakpoint is valid as I hit it when I launch automatically from Xcode.
Cleaned build folder, restarted Xcode etc, no avail. My code is simple as I've just created a default project:
int main(int argc, const char * argv[]) {
#autoreleasepool {
// insert code here...
}
printf("aha");
return 0;
}
In my project settings, I've set a custom location for my executable for debugging to be deterministic (I don't want Xcode to append random strings into the build data in derived data folder):
Why am I getting this error? How can I debug my executable upon launching from terminal?
Are you showing the app code just as an example or is that what you are really trying to attach to? The attach wait works by sampling the process list till it sees a process of that name, then attaches to it. So depending on how far the process has run before lldb manages to attach to it, it may very well have executed the code you set the breakpoint on before it attached. Especially if not much goes on before the breakpoint.
The best way to arrange to attach to something that you need to run in terminal is to put a spin in the program, like:
int keep_spinning = 1
while (keep_spinning)
{
sleep(1);
}
the when you attach, you can set keep_spinning to 0 and continue.
I had this problem with a (command line) unit test implemented with Google gtest, using Xcode 10. My session used "attach automatically", but I had the same problem, consistently. I had a breakpoint set near the beginning of a test case (the only one), and it never stopped, and I got the same message. Even stranger, I got it when I removed all breakpoints and simply tried to run through the program using the debugger. I was however able to get the breakpoint I wanted by setting another breakpoint early in the test's main() function. That can be tricky with gtest, because it's possible to use a generic main that simply launches all tests. Fortunately for me, we roll our own shared main. I put a breakpoint before the call that runs all the tests linked with our main, and it stopped politely as ordered. Then when hit the "continue" button, it stopped at the original break that I wanted. I have no idea why this would work when other things did not, but if anyone else is having a problem like the above, I recommend putting a breakpoint as early in the program as possible and check to see if it gets you out of this particular bind. If you happen to be in EXACTLY the same situation I encountered (that is, you are using a gtest unit test), note that no matter how early in the test instance itself I tried to break, I got the same failure mode. For me, it had to be in main. Best of luck.
Where XCode generate error for application crash ?
I'm crazyng ! My application when open second file xib with webview then it crash. But I don't know why ? how can i Know where is error ?
You need to learn how to use the debugger in Xcode.
Run your app under the debugger then instead if simply getting a stack trace Xcode will stop at the line the fault occurs and show you your code and variables. You can then examine the contents of your variables, the call tree, etc. and hunt down the problem.
Once you know the general area of the problem you can place breakpoints to pause your application before the problem occurs and check whether your variables have the values expected etc. Then you can run till the next breakpoint, or step through your code a line at a time.
You can add code, such as NSAssert's and NSLog's to your app to check progress and display information without stopping the run, etc.
It's a process, and some problems will be harder to track down, but you'll get quicker at it with practice.
The Xcode documentation will tell you all about the debugger.
HTH
I'm trying to add support for tracking application usage to a WP7 app (e.g., how many times has the app been run, including wakeups from tombstoning). I thought I was doing this in a pretty straight-forward way, but I'm frequently getting IsolatedStorageExceptions, and I'm kind of at a loss for debugging it at the moment.
Paraphrasing from my App.xaml.cs
private void HandleAppCounter() {
int i = 0;
settings.TryGetValue<int>("usage", out i);
i++;
settings["usage"] = i;
settings.Save();
}
I call this function when the app is launching or activating. The thing is, it works just fine. But the thing is, if I make another call to isolated storage soon after then that is what blows up. And furthermore, it seems to only blow up if the next call happens pretty soon after.. although I'm having trouble understanding that as well.
The next action performed is usually a user clicking an item in a list. If it happens immediately when it's displayed, I get a crash from isolated storage. If the user waits a few seconds after the app is launched and then clicks it, there is no crash.
If the above code in HandleAppCounter() is commented out, then the user can click either immediately or later and it never crashes.
Can anyone give me some tips on how to debug this? I'm kind of running into a wall here.
I would suggest stepping away from your custom implementation for a sec and try the same behaviour with the default IsolatedStorageSettings class, if it is still a problem then you should report it to Microsoft Connect site as a bug, otherwise there is some kind of an error in your settings class.
If you're using IsolatedStorageSettings you might want to make sure, that whenever you're querying/adding a key, the key is there, if not you must create it.
If you're using IsolatedStorage filesystem then make sure you are always closing the streams when you're reading/writing. If you don't you will get absurd exceptions.
I am trying to launch an application via the ShellExecute() API call. This application contains only a main function which does some processing and exits.
Now I have put DebugBreak() in starting of main. When ShellExecute() is called the application is launched successfully but it does not ask for breaking.
How can I debug my application when launched from other application using ShellExecute()?
I am using VC++ .
If DebugBreak() isn't workign for you, try _CrtDbgBreak(). Note that _CrtDbgBreak only works in a debug build.
_CrtDebugBreak definitely works for me to make a launched process break on startup, although I'm pretty sure DebugBreak does also.
Note that both functions will make it look like the process has crashed, since they raise an exception. That is normal and gives you the opportunity to attach a debugger via the crash dialog. (The crash dialog also lets you terminate the process; don't use that, obviously.)
Also note that if you have a catch-all SEH exception handler around your main then the exception raise by DebugBreak & friends will be swallowed up and the app will simply exit without showing the crash dialog or letting you attach to it.
You can't do this with VC++; with WinDbg this is just .childdbg 1 to debug all child processes. With VC++, you can use Image File Execution Options in a pinch - check out http://codereflect.com/2009/09/20/how-to-debug-child-process-using-windbgvisual-studio/ for more info. Really though, if you've got the time to learn WinDbg, it's much better at this.
you can try this, it's ok in xp system.
app.exe is your application name,
-s1...-s3 is command line arguments.
HINSTANCE hRet = ShellExecute(NULL, L"open", L"vsjitdebugger.exe", L" app.exe -s1 a1 -s2 a2 a3 -s3", szExePath, SW_SHOW);
There is now a Microsoft Child Process Debugging Power Tool.
The method I use for things like this is to embed some interactive code, which you can either delete afterwards, comment out or conditionally enable. In a few cases we have this code enabled by querying an environment variable which is set by the tool that launches the main application. This allows me to click a check box, hit launch and have the breakpoint dialog in seconds.
if (MessageBox(NULL,
_T("Attach the debugger now, then choose Yes to hit a breakpoint"),
_T("Attach Debugger"),
MB_YESNO) == IDYES)
__debugbreak();
This gives you the ability to attach the debugger when the dialog box appears and the option to hit a breakpoint or not. My earlier versions didn't give me the option and after a while I realised some of the time I wanted the breakpoint, and some of the time I didn't.