I'm noticing an unexpected and undesirable behavior out of IntelliJ's debugger that I'm wondering if anyone knows anything about.
Our Spring app has some fairly complex shutdown logic. We make use of Spring's "Disposable Bean" interface, and we also register our own JVM shutdown hook. I often find myself wanting to stop in the debugger in this code. I'd love to be able to do so by pressing the IntelliJ debugger's Stop button and having my breakpoints be hit. This is the behavior I expected.
When I press the Stop button in the IntelliJ debugger, my breakpoints in my shutdown code are not hit. At first, I thought that maybe IntelliJ was hard-killing my app rather than sending a termination signal (I believe it sends a SIGINT) to the process. But I have since confirmed that my shutdown code runs when I press the Stop button. The behavior is as though IntelliJ unregisters my breakpoints before sending the SIGINT signal to my app.
My workaround is to send a SIGINT to my app from a shell prompt. When I do this, my breakpoints get hit. This is a pain. So I'm wondering if anyone has either a way to cause the breakpoints to be hit when the Stop button is pressed, or at least some information as to why the debugger behaves this way.
Just as #Rogue guessed, when you click the stop button, the IDEA disconnects the debugger and sends SIGINT to the app.
There is no setting to configure this behavior currently. Check the related issue here for details: https://youtrack.jetbrains.com/issue/IDEA-170313/Breakpoints-not-working-after-stop-signal
As a workaround, you could open Settings | Tools | External Tools, add a script that could find your java process, and send the SIGINT. Then assign a shortcut for it or add a menu in the IDEA's Toolbar in Settings | Appearance & Behavior | Menus and Toolbars so you could use it easily like the stop button.
Related
I am writing a simple program in Java, and sometimes it randomly freezes and does not respond. when I try to end it with Ctrl-C instead of quitting, the program springs back to life and starts working fine again. I am not posting my code because I have noticed this behavior with other command line programs on Windows, so it does not appear to be anything specific to my code. The program will eventually be running 24/7 on a headless server, so you can see why it would be a serious issue if it just stopped working every now and then. Thanks in advance. Any help is appreciated.
This sounds a bit like perhaps a selection issue: If you make a selection in the console window, it freezes console output. The next time an application attempts to flush to the console it will stall until the selection is cleared. Pressing ctrl-c will copy the selection and clear it, allowing the flush to complete and the application to continue to run. Any keypress in the console window should clear the selection though, and it sounds like only ctrl-c is working for you.
If that's not what the issue is, your next best bet the next time you see this would be to open up a native debugger (e.g. Windbg) or a java debugger and attach to the process you're running in the console process to see what is doing the waiting. It's likely that something you're calling is triggering a spurious getch / readline / etc. A debugger should make the source of the stall obvious. If you need help deciphering the stack once you have one, I might be able to help. Just paste it into this thread.
Ben
My project is basically a Communication client like lync which is developed in JAVA for front end (GUI) and uses platform specific native (C or C++) code for running services.
Now, on Linux, (Ubuntu 12.04), once the JAR application is invoked, it loads all the native code shared libraries and the UI thread starts executing. Any action done in the UI will throw an event to the native code which is in C. So currently i need to debug a crash in a C/C++ user library which is triggered when i do something in a UI drop down.
I am using GDB, to attach to the PID of the process , (sudo gdb -p ), all the symbols are loaded and i am able to set a breakpoint to a function say A() in the library.After continue command in GDB, i select the instance from UI Dropdown and breakpoint is hit at Function A(). At this moment, my ubuntu machine hangs and no keyboard interrupts are working. I am only able to move my mouse pointer but cannot click on anything.
However, to verify that kernel is not down, i can ping the machine and even SSH is possible. Once the same GDB is invoked by SSH the above problem is not encountered. May anyone please help me out here as to why UI or X11 process hangs during the above scenario.
PS: Yes there are lot of threads running, it might be a thread deadlock situation but it does not happen when GDB is invoked by SSH terminal.
Thanks and Regards,
Indra
why UI or X11 process hangs during the above scenario
As Mark Plotnick correctly pointed out, the X11 process does not hang. Rather, it grabs the keybard (all keyboard events are dispatched to it), and can not release that grab (it is stopped by GDB before it reaches the release point).
There are two common solutions:
ask the application to not do the keyboard grab (as Mark said), or
debug the application from a separate machine (this can even be done on single physical machine: just run the application inside a VM).
P.S. Why do application menues grab keyboard? Because hitting Esc usually dismisses the menu, and they want to see that Esc regardless of whether the application has input focus or not).
I try to make an application which must be full screen. But when i press CTRL+ALT+DEL task manager comes up. Even i disable task manager, at this time its error message comes up and make taskbar visible. Then user get the chance to go to the dekstop but i dont want user to get this chance. Only user could be able to go to desktop when it did what application wants from it. So i need taskbar keep bottom of other windows until user does what it should do. And i need to do this by my application which i try to code in Java
How can i change the status of task bar using registry?
Why not permanently disable the taskbar?
Follow this link to permanently disable the task bar.
You can edit .reg files in Java, follow This link to know how to edit .reg files
"But how can i do it by java without reseting the machine?"
As far as i came across, you have to reboot your system, no way out.
Ok i found it.
When i changed the value of 8th byte value of Settings variable to 10 in
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StuckRects2
in registery
It just deselect the "Keep the task bar on top other windows" option
For applying the changes explorer.exe should be killed and re run
There are key strokes which Windows catches before they are sent to application and Ctrl+Alt+Del is one of those.
Regarding "Then user get the chance to go to the dekstop", if you set frame.setAlwaysOnTop(true);, user won't be able to switch to other any application.
You can use java's fullscreen API, and then use a Robot to force focus back to your application. See here: Java Full Screen Program (Swing) -Tab/ALT F4.
Good luck in whatever you are doing - it doesn't sound fun!
I made a java application that saves data to a .data file. I have a Window Listener that listens for the application to close in order to fire the code to save the data to the file. When pressing the dedicated quit button I have, or pressing the red "X" on the window, everything is fine. However, when the user opts for the command + q route things go sour. The application is quit, but the data is not saved. How do I correctly implement apple's handleQuit(Application Event e) method to fix this?
What you want in that case is a shutdown hook. A shutdown hook listens for the OS signal to close the app and is triggered when this signal is sent. A shutdown hook can run pretty much any code.
You can wire your built-in red "X" button to close the app (instead of saving the file), and the shutdown hook will catch the request and take care of saving the file.
The only caveat is that shutdown hooks are supposed to be made up of code that doesn't take very long to execute. So, the save of your file shouldn't take more than a second or two, and you shouldn't use confirmation dialog boxes that the user must acknowledge in a shutdown hook, because it can take an indefinite amount of time before the user recognizes the dialog.
The reason why shutdown hooks should be short lived is that when an application is requested to shutdown, the OS generally expects it to shutdown in a reasonable amount of time. If it doesn't, for example in Windows, the OS might display one of those, "Application isn't responding..." messages.
Finally, and you might run into this question later, you might wonder how to catch a "Force Quit" request from the Task Manager (or "Force Quit Applications" dialog on OS X). Well, you can't catch those, and you shouldn't try! While it is possible to disable things like listing your app in the Force Quit menu, this is a complete hack and should be avoided at all costs. If you're designing your app in a way that tries to circumvent options that should always be available to users and admins then that's a strong indication that your app is poorly designed, and/or a bad actor. Imagine if you installed an app that behaved in this way - wouldn't you think the programmer was being lazy or possibly malicious in trying to give their app un-killable qualities?
Also, force quitting is a forcible (ungraceful) shutdown that should only be used on applications when they are hung and won't quit normally. OSs need to have a force quit kind of option so that a user or admin has a way to kill a runaway or unresponsive app. If your users are force quitting your app they either misunderstand that force quitting isn't desirable, or there's something about the design of your app that makes force quitting more favorable than quitting your app normally. If this is the case (e.g. you hear from users that they force quit for one reason or another), it's usually an indication that portion of your app is poorly designed to match user's expectations.
Is there a way how to stop debugging when program hits the breakpoint (i.e. I don't want to execute the code after it) without stopping entire application server (I am programming apps in Java, server is JBoss)?
I know only one way how to stop debug - red button with title Terminate which shuts down the server. So is there anything else?
While debugging, context menu offers you to force a return. This instantly leaves the method and will take you back to the caller. One can also use Alt+Shift+F.
If you mean "I do not want the code after my breakpoint to execute", then you could use a conditional breakpoint to execute a return from that method.
(Note that you can execute any code you like in a conditional breakpoint. It does not have to be just a condition.)
You can hit the disconnect button. See the attached image. This will continue execution and stopping debugging without stopping the server.