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.
Related
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.
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
Somewhere in my program is a infinit loop. I start the programm and it does not stop. Since I have no idea where the issue is, I can not use breakpoints.
Is there a way to start debugging manually after a given time in Netbeans? Then the curser should be inside the invalid while loop.
When you start your program in debugging mode you can hit any time "Debug/Pause" and see under "Window/Debugging/Call Stack" where your program currently is.
Another idea would be to use the profiler to see which method uses more time than expected.
I'm debugging a normal Java application, no GUI, just a lot of computations and ~5 calls in the stack for the main thread when the problem occurs. Basically it keeps saying "Collecting data" in the local variable watch.
So instead of going step-by-step I've tried to add a breakpoint immediately after an press "Resume". Now it says "Waiting until last debugger command completes".
Have anyone had this problem before? Is changing the debugger the only way to figure this out?
On IntelliJ (2017.1.4 Community Edition), the following fixed the problem for me:
File->Settings
Type in "toString"
Navigate to Build, Execution, Deployment->Debugger->Data views->Java
Find the "Enable 'toString()' object view:" checkbox
Uncheck the box
Re-run the debugger.
The following fixed it for me on IntelliJ 2018.2.4:
Right click breakpoint
Toggle the setting to suspend "Thread" instead of "All"
This won't be helpful if you actually need to suspend all the threads for debugging, but it got rid of the "Collecting data..." and "Waiting until last debugger command completes" messages for me. The setting also persists for subsequent breakpoints, so you only need to change it once.
I just ran into what looks like the same issue. In my case it was a class (KafkaStream) in the breakpoint stack trace with a "bad" toString method. The toString method blocks and therefore hangs the debugger. I tested the toString method in the main line code and it hung the main thread (i.e. this is not a debugger specific issue).
Here is the stack trace for my thread that hit the breakpoint (on a line that was just trying to test a boolean attribute of my class):
Intellij provides a way to work around for my issue. It allows you to override how the debugger renders the class:
If your issue comes back I suggest taking a thread dump (inside or outside of the IDE) and see what your thread is doing.
In most cases, it would be because of the watches that you add while debugging.
Clear the watch statements that would result in recursive execution of same statements as in the code.
Always keep the watches clean before debugging.
It happened to me once (on version 2020.3.3) and "Invalidate Caches" and restart solved it.
The fix that worked for me was to remove method breakpoints. That made it superfast.
I am currently developing a java application, I am trying to use the builtin debugger in Netbeans. I wanted to know how to trace back in the debugger.
Assuming I am executing the instructions line by line, if the program is currently executing 105th line of code and if i would want the program to go back and execute the 103rd line of code, how do i do it? Is this even possible ?
Please read the below link. There is a concept of Pop Topmost Call which might help you.
http://wiki.netbeans.org/FaqDebugBackup
You can do that by setting a break point on 103 line. Then go the call trace and then on the call before to the current right click and do drop to frame. It will re execute that part. Then it will hit you break point on line 103.
I suggest you don't dot it multiple times in the same run. the state of the system becomes unstable for the run by doing this over and over again.