I have to develop new features and change some extisting ones in a buggy extensive Android application (where any changes may affect completely "unrelated" part of code) and I encountered a bug where application freezes (not responding).
So I figured it is probably a deadlock. But how to debug this? I cannot go step by step since we have many threads running and I dont know where to put a breakpoint...
Is there any way to break in debug and get a line (or part of code) where application is currently running?
Hope its not too chaotic, but I am exhausted from hours of testing...
If you are using eclipse.
You can suspend the debug session from the debug view.
Check the threads currently in action
From the stack trace of threads you can get a fair enough view of the current situation.
For further investigation you can use JConsole to debug the deadlock.
Check here https://kellicker.wordpress.com/2010/05/03/deadlock-debugging-in-eclipse/
cheers,
Saurav
As your app is multi-threaded, the best option may be to make use of debug logs in your code. You may get some clue about the part that is causing deadlock.
Related
Intelliji idea is very slow in debug mode and it is running perfectly in normal mode.
I already tried by setting the below thing in /etc/hosts file
sudo nano /etc/hosts and add these two entries.
127.0.0.1 .local
::1 .local
But it did not work out for me.
Any help on this is highly regarded.
Remove breakpoints off your method and use them inside the method as that can cause your debug to take a very long time.
Try running IntelliJ as admin. I had this issue at work where debugging was extremely slow and running as admin actually made it a lot faster.
Method breakpoints may dramatically slow down debugging
There is a simple explanation from the IntelliJ Team: "Method breakpoints will slow down debugger a lot because of the JVM design, they are expensive to evaluate"
https://intellij-support.jetbrains.com/hc/en-us/articles/206544799-Java-slow-performance-or-hangups-when-starting-debugger-and-stepping
I had the similar issue. In my case it was method breakpoints. There was just one break point on a method. My spring boot app took around 20 mins to launch. When I removed the breakpoints it took 4 seconds to launch.
I also changed the debugger settings.
Unchecked - Enable alternative view view for Collections classes
Unchecked - Enable 'toString()' object view:
but these settings didn't make a difference.
If you disable this options in Build, Execution, Deployment -> Debugger -> Data Views --> Java, things will start work faster when debugging.
I have solved a similar problem by disabling breakpoints; it was remote debugging.
I did not make any performance measurements, but it looks like it is ok to have about 10 active breakpoints, but disastrous to have about 100 of them (I guess, the breakpoint list is sent over the network).
Idea lets you to group breakpoints and disable the whole groups.
Note that a click on the wrong mouse button clears your breakpoint instead of letting you edit its condition, so be careful!
clicked on "Mute Breakpoints" and started it and it started like as if starting in normal mode(means no any delay)
Make sure that you don't use "biz.paluch.logging.gelf.logback.GelfLogbackAppender" among your logs. In my case usage of such kind of appender was the cause of drastically slow starting in debug mode.
In my case I just had to disable the option: "Show method returns values"
Image of the option
I also faced same problem, after deleting all breakpoints it started working fine.
I faced similar problem with the Eclipse also and found the solution.
It is happening because your IntelliJ is using online Java and not using the same which is installed in your system.
You should set the java path to your system one in the IntelliJ configuration. Below link will help you for the same:
https://intellij-support.jetbrains.com/hc/en-us/articles/206544879-Selecting-the-JDK-version-the-IDE-will-run-under
Hope this will help you. :-)
Remove breakpoint from DAO interface and all work nice!
In my case i had more than 100 breakpoints active and this was the cause of this issue.
I clicked Ctrl + Alt + F8 and disabled all the breakpoints.
After that i enabled few new breakpoints i needed and all was ok.
It seems that having a lot of active breakpoints causes this issue.
In my case, slowness is specific to REST calls. After testing all of the above proposed solutions, I finally find a way to remove these slowness issues by switching my JDK from JDK 11 to JDK 8.
Note: The same slowness appears in Visual Studio Code. This seems related to JDK 11 (OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode) on macOS)
Removing all Interface method breakpoints will fix the long spring boot startup Idea debug run.
In my case the problem was caused by the "Threads" view. When I remove this view it becomes fast again.
When I add the Threads view, I continuously see "Collecting data..." in the threads view, it flickers every 5s where the threads list shows for a moment then it goes back to "Collecting data...". When its like this, stepping through the code is painfully slow - takes about 10s for each step.
I cam across this post looking for a solution for my CLion (Rust). I removed all breakpoints, and it was enough to make the starting time on the debug mode too quick again.
Thanks to everyone who suggested that. This suggestion does not work only for Java, it also works for Rust/Clion
I have a problem while debugging in IntelliJ IDEA, it hangs in debug mode on break point in listeners in javafx application. I tried to increase heap space, but it's not help. Maybe someone had such problem too, please, suggest me what to do.
Set this as a VM parameter:
-Dsun.awt.disablegrab=true
It will mess up drag-and-drop, and leave an artifact on your screen while the debugger is paused - but it will let you debug. It happens whenever you block the JavaFX thread.
This can happen for a simple reason: The application has a lock on the desktop, for example a modal dialog or a popup or an open menu. Then it stops in a breakpoint. This notifies the IDE. Now the IDE tries to do something on your desktop but can't since the application still has a lock on the whole desktop -> deadlock.
You can use a tool like Chronon which records the whole program and lets you move back and forth on the timeline.
The last option is logging or poor man's debugger (System.out) instead.
[EDIT]
it's hard to check with System.out which of 20 parameters not equal.
It's actually pretty easy:
System.out.println("check");
if(!a1.equals(b2)) System.out.println(a1+"!="+b1);
Then duplicate the last line. That way, you will only get output when something is actually interesting (and not for the 19 equal parameters). Add some patterns to the output if you can't distinguish aX from aY (i.e. both are true):
if(!a1.equals(b2)) System.out.println("a1:"+a1+"!="+b1);
I am debugging an application with lots of threads. My breakpoints are set to suspend the whole VM.
When a thread hits one of the breakpoints, I then want to use Step Over. But this appears to resume the whole VM, until that step completes.
It'd really help if I could step just the single thread that hit the breakpoint.
Is there any way to do this in IntelliJ 11.1 / Java 6? (Hope I'm not missing something obvious...)
This feature was added in IntelliJ 16 (the issue CrazyCoder referenced in his answer was resolved)
More details here:
https://blog.jetbrains.com/idea/2016/02/intellij-idea-16-eap-improves-debugger-and-adds-git-worktree-support/
NetBeans can resume individual threads. While in debug mode, you can resume a thread from the left thread list by pressing a small button shaped like Play (►) near the thread.
Currently there's no such possibility because it may lead to deadlocks. You may vote for IDEA-43728 though.
We are working on a large Java program that was converted from a Forte application. During the day we are getting Blocking SPID's in the server. We had a DBA visit yesterday and he set up a profile template to run to catch the locking/blocking action. When we run this profile the blocking problem goes away. Why?
This application is distributed using RMI and has around 70 users. We are using SQL 2000 and windows 2000 servers to keep compatibility with a bunch of old VB helper applications.
We have traced the blocking down to a specific screen and stored procedure but now we can't get the errors to happen with profiler running.
Thanks for any help!
Theo
The good old Heisenberg debugger problem.
Any profiler does two things: it adds code in place to invoke the debugger, and it stores data. The first one can thward optimizers, and the second can change the timing of something, causing a race condition to go away.
This blocking SPID problem seems to show up on Google a lot; the reason appears to be that it occurs when some resource is locked when another one wants it, so the timing error sounds likely.
Microsoft has an article on how to deal with the problem.
Just a collection of random thoughts.. I've seen traces take a server down but never make things better.
What trace template are you using? (These are taken from SQL Server 2005 tools, sorry)
The "Standard (default)" one tracks high levels calls and logon/logout
The "TSQL_SPs" tracks statement calls which would be a lot more intrusive
Is it binary and guaranteed too? Trace on= no blocks, trace off = blocks, or is it unlucky coincidence? When you're all watching the DBA does someone stop clicking in the client and come to watch?
Is something else being switched off as part of the trace. That is, are you using profiler or a scripted trace (lots of sp_trace_set% statements)?. In a scripted trace, there may be something that switches something else off.
It is Hallowe'en after all.
Here's the problem: I'm maintaining some old-ish J2EE code, using Quartz, in which I'm running out of threads. jconsole tells me that there are just short of 60K threads when it goes pear-shaped, of which about 100 (!!) are actually running. Intuition and some googling (see also here) suggest that what's happening is something (I'm betting Quartz) is creating unmanaged threads that never get cleaned up.
Several subquestions:
It there a tool that I can use easily to trace thread creation, so I can be certain the issue is really Quartz?
Most everything I've found about similar problems references Weblogic; is this a false lead for Tomcat?
Does anyone have a known solution?
It's been years since I did J2EE, so I wouldn't be too surprised if this is something that can be solved simply.
Update: It's clearly increasing threads without bound, see this plot from jconsole.
Try to increase the logging level of org.quartz.simpl.SimpleThreadPool to debug to get more information.
If that does not work, try a logging listener. Quartz has a JobListener interface, which is specified in its tutorial. A listener can help you trace job execution. Maybe jobs just don't finish and get deadlocked.
Configure org.quartz.threadPool.threadCount to stop running out of threads.
update:
Also, you might want to take a thread dump and see the thread stats. visual vm has a plugin called TDA, or you can use Thread dump analyzer directly.
Just in case, check the quartz version to see if there is no known bug.
Have you had a look with jvisualvm - it gives some more information.
Also, get stack traces to see what the threads are actually waiting on. You might have an aha-feeling right there.