I'm debugging a Cocoa application that can act as a handler to a custom URL protocol. The application works fine when I click on a link after the application has launched, but something is causing the app to crash if it has not launched at the time the link is clicked.
Is there any way that I can start the app in the debugger and "fool" it into thinking that I had just clicked on a link?
You can do
gdb --wait myAppName
and then click on the link to launch your app. This will cause your app to break into the debugger very, very early, before main has started.
Could you attach to your process from XCode once the URL handler has been invoked? You could try putting a modal NSAlert in your URL handler code so that will pause it until you can attach to your process.
Related
I linked my application to a file extension, so when i double click those files it opens my application. However i experience crash when doing so, and i am looking for a way to breakpoint that and see what's going wrong. I'm using Xcode, it's an OSX app.
Any idea?
lldb doesn't have a "launch with open AppleEvent" feature, so you can't do this directly.
But you can use lldb's "attach wait" feature to catch the app early in startup. You can do this in Xcode by turning on "Wait for the executable to be launched" in the Info tab of the Run scheme of your App target. Then click the Run button, and go to Finder to launch your app by double-clicking on one of its files.
If your system is not heavily loaded, lldb will generally stop the app pretty early in its startup, usually before it gets to handling the open event. Xcode will auto-continue the app, so it should just proceed right to the crash.
If for some reason lldb doesn't attach early enough, edit the main function of your application, and at the very top put in:
int go_on = 0;
while(!go_on) {
sleep(1);
}
That way your app will stall in launching before it handles the open event, giving
lldb time to attach. Once it has attached, Pause the app in the debugger, select the thread and frame containing this main function, go to the lldb Console and do:
(lldb) expr go_on = 1
and then continue. Now your app should finish starting up, handle the open event and crash into the debugger.
As a complement of Jim's answer: If your application is responding to the kAEOpenDocuments event through
- (void)handleAppleEvent:(NSAppleEventDescriptor *)event
withReplyEvent:(NSAppleEventDescriptor *)replyEvent
you can debug your application using Xcode as usual, and set a breakpoint on the line where you start to process that event (or at the beginning if it crashing before reaching that point). Once set up, go to Finder and open the file.
Take into account that when double-clicking it will launch the default app, so if your debug build is not the default one you have to choose "Open With > Other...".
I have an Electron app, running on Windows, it has a few controls on the main window and a cancel button. I notice when it is running I see two threads, I assume the main and renderer threads. When the cancel button is clicked the renderer sends an IPC message to the main thread and the main thread calls app.quit. Under these conditions the two threads end. If I right click on the icon in the Windows taskbar for the app and select "Close" the threads only end when the app is run under the VSCode debugger, when the app is run without the debugger and the same is done the two threads remain.
How can I debug this? Any suggestions as to why it is happening.
Under the debugger I see the close being caught in the main thread and app.quit is called.
UPDATE: Since the app used Electron 1.7.9 I have updated it to use 2.0.8 just in case this was an issue that had been addressed. However, with 2.0.8 the issue remains.
Sid
Thanks to some input from the Electron Slack community I have resolved this issue. My mistake was in the way I was calling the app.quit() method.
My code was handling the MainWindow on "close" event and executing the app.quit() method in that event handler.
The correct way to close the app is to handle the app "window-all-closed" event and execute the app.quit() method there.
Here is a gist of a skeleton main.js for an Electron app that was sent to me to help me resolve the issue.
https://gist.github.com/sidprice/612cb49cec923eeb94cfcddf1736c181
Sid
I'm seeing a strange behavior with my simple NativeScript / Typescript app. In the app.ts i launch the application like so:
app.start({ moduleName: "pages/home/home-page" });
but debug break points in home-page.ts in the loaded and navigatingTo event handlers don't stop execution. however when in the app i click on the Home page link the events are fired and the break points are stopped. So it looks like the app.start call does not fire page lifecycle events at all.
Seems like a strange behavior. Any ides?
It appears that the application is being executed too fast and the debugger doesn't have time to attach. To fix this problem in the launch.json (debugger configuration in VSC) set
"stopOnEntry": true
This will stop the application on the first line and allow time for the debugger to attach.
Hi I want to make a small test window app that can force IE to save its data and shutdown upon a button click and restart with same tabs when another button is clicked??
I am fairly new to Win32 programming can anyone help me out here.??
Any leads will be appriciated??
Try to find one of each browser class with EnumChildWindows then you save the text(current link) of each one, and send a WM_CLOSE message to the program, if you debug the IE you'll probably see a CALL to the function to open a new window, when you find it, you can call it again and with the new browser class you put the text you got from the one that was opened
I'm seeing some unexpected things happening in the emulator.
When debugging and starting the app for the first time, the Application_Launching fires just fine. When clicking the start button, the Application_Deactivated event fires fine. When click the back button, the Application_Activated event fires fine.
If I click the start button then go to my apps and launch my app, no events are fired. I would assume either the Application_Launching or Application_Activated would fire when the app is launched every time, just a different event depending on how the app got there.
Is this an issue with the emulator or do I have the wrong assumptions here?
Well, the events get fired right. What you missed is that debugger get dettached when you are launching "new instance" of your app. ;)