We Keep Coding

Debugging deadlock on Android in Eclipse

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.

How to track down seemingly random crashes in Java?

While doing some homework that works with some swing gui components, my program started crashing seemingly at random. That is, it starts, runs for a short time, and then crashes. I don't get any errors in the console, it's just a straight up crash.
I don't doubt that it is something I wrote, and I'm more than happy to show code if anyone wants to look at it, but is there anything that I can do myself to track down what might be the cause of my crashes?
Some other information that might be useful:
I'm using eclipse, and the debugger doesn't seem to do anything that helps me with this (program still crashes).
I didn't notice any issues like this until I started to add event handling.
I'm using Windows 10.
Occasionally, nothing is drawn in the window I create. Exiting and then running the program again will cause it to work.

Some possible heuristics:
Crashes that occur seemingly at random suggest incorrect synchronization; look for event dispatch thread violation using one of the approaches cited here.
Verify that all exception handlers produce diagnostic output; run from the command line to ensure that diagnostic output has not been inadvertently redirected.
Try running under the aegis of a different debugger, e.g. NetBeans.
Try running under the aegis of a profiler.
Try a different version of the JDK/JRE.
Try a different host OS.

With Swing & Java, what is done by the "Swing-Shell" thread

with threads & swing, the event queue (event dispatch thread) is broadly presented & discussed.
However, when examining the thread states with a Swing application, there's also a thread named Swing-Shell. With brief googling I couldn't find much details, mostly thread stack traces with bug reports etc.
Can somebody describe shortly what that thread does. Or even better, does somebody have some link to some documentations
EDIT: I was asking too fast without enough details, sorry. I was going though various
JFileChooser issues and a thread named "Swing-Shell" occurs there, having
something to do with Windows COM services for file system.
A sample stack trace within a deadlock problem can be found at
Sun Bug #6741890.
(The thread stack trace starts with sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run).
With closer inspection with jconsole, I noticed that the thread isn't present there until
I have used JFileChooser (JFileChooser for example; the Swing-Shell thread will probably be started
by any components using Win32ShellFolderManager)
The thread seems to exist also after the usage of JFileChooser.
So, answering to myself, the thread seems to be a separate thread used for COM services with
file-related operations (with Windows only? ). If somebody can provide more details, welcome =)

The number, purpose and naming of initial threads is implementation dependent. On my platform, the event dispatch thread (EDT) is named AWT-EventQueue-0.
Addendum: The only other reference I found says, "A Motif application uses a shell widget to communicate with the window manager." Are you using a Swing library of some kind?
As suggested above, a thread dump might be illuminating. Recent versions of NetBeans' profiler include a save button; I've attached a snapshot of the threads in a typical busy demo.

Java Swing app hangs when run in normal mode but runs fine in debug mode

I am writing a basic Java application with a Swing front-end. Basically it loads some data from a Derby database via Apache Cayenne and then displays it in a JTable. I'm doing my development in Eclipse and I don't think it's important but I'm using Maven for dependencies.
Now this works fine when I run using Debug but it seems to hang the display thread when I use the Run button. I've done a thread dump and I'm not 100% certain but everything looks good. I used Java VisualVM and the threads look fine there as well.
Strangely it seems to work intermittently. It's pretty consistent though and easy to reproduce. If anyone has any ideas, I'm all out of them.

It shouldn't be an issue that you are using Maven or Eclipse for Swing apps. We do that all that time with no problems. You said you're not 100% that everything looks good with the threads, so a posting of your threads would be useful, particularly when your application is hung - it's possible you have a deadlock.
The fact that you say it happens intermittently leads me to believe it's a threading problem. The debugger running may cause the threads to run differently, which is why it might work in debug mode. Swing threading issues are frequently caused by not performing GUI updates on the event dispatch thread since Swing is not threadsafe. Any operation that updates a swing component directly or indirectly (meaning if it updates the table model, which then updates the table) must be done on the event dispatch thread
If you can narrow down the block of code that is being invoked when the application freezes, you should post that if you can, and that would be helpful as well.

Zombie threads eating my brainz (J2EE, Tomcat, Hibernate, Quartz)

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.