We are experiencing a bug we cannot track down where something is freezing up our swing thread (it's been almost 2 weeks now and no real results) - we are experienced Swing programmers but we have a huge program and believe it to be in some of the legacy code
I am wondering, is there any way outside of editing the actual EventQueue class in the JDK which will allow us to view all pieces of our code currently running on the Event Dispatch Thread - maybe some type of tool which will allow us to view things as they enter or leave the event dispatch thread?
One interesting approach is to extend EventQueue and push() it, as shown here.
Logging everything that passes through the Event Dispatch Thread seems a cumbersome way to diagnose a freeze. Wouldn't it be easier to wait until the problem occurs, and then ask the Event Dispatch Thread what it's doing now? One way to do this is to enable JMX monitoring, connect to your running process with a JMX client such a VisualVM (which ships with the JDK), wait for the problem to occur, and then take a thread dump.
In case you still wish to log everything the Event Dispatch Thread is doing, you can do this by:
In Eclipse, launch the application in debug mode.
Create a breakpoint on EventQueue.dispatchEvent, right-click it, select "properties", check "condition", and enter the following "condition":
System.out.println(arg0);
return false;
It might be good idea to try BTrace to instrument the EventQueue and capture stack traces each time something gets added. I think the latest VisualVM has plugins that will allow you to instrument a running JVM with a BTrace script.
If you're using the Oracle JRE, there is a TracedEventQueue included already. You can install it as mentioned before:
EventQueue eventQueue = Toolkit.getDefaultToolkit().getSystemEventQueue();
eventQueue.push(new TracedEventQueue());
Note, this will output a lot of output...
Related
Back when I was using Eclipse for Android development, it was possible to select a thread and freeze it - so it would not run. This allowed the debugging of one thread without interruptions from other threads.
How can a thread be frozen - prevented from running - in Android Studio. I have found the list of threads but I do not see any controls for freezing a thread.
--------< additional information >----
2 people didn't understand the question, so let me try again.
In Eclipse, when debugging a multi-threaded app, you can suspend and resume threads in the debugger.
In the above image, you see the Debug view, showing a list of threads. Right mouse on one of these threads and in the menu is Resume, Suspend, Terminate. These menu actions apply to the selected thread.
When debugging multi-threaded apps, sometimes it is essential to suspend a thread temporarily.
In Android Studio, I can get a dump of the threads, and selecting each one shows me its stack trace on the right.
But I can not find any way to suspend and resume the thread.
Again this is a critical requirement of a debugger.
Does anyone know how this suspend/resume can be done in Android Studio???
I haven't looked under hood to be sure of this, but I imagine that it is using JVMTI. This "hooks into" the JVM at a lower level than is possible through the APIs in the Java class libraries.
And, before you ask:
I doubt that JVMTI is available on a real Android device. (I don't know if there is an equivalent.)
A Java application using JVMTI to control its own threads would be a really bad idea. Think about the reasons that Thread.stop and friends were deprecated, and multiply by 10.
I am working on a Java application which has a threading issue.
While using the applications for some time with Netbeans profiler attached, I can see several threads are created. Most of them finish in some .5 seconds. I could only find SwingWorkers used in the application.
Moreover, the majority of threads displayed by the profiler are normal threads and not SwingWorkers. Unless these threads were created by SwingWorker indirectly, I suspect, some library that the application uses is creating them.
Now I would like to remove this issue. But I could not find a way to determine the source of thread creation. If you can please suggest some other profiler/tool by means of which I can find the source(method) of thread creation.
If using Eclipse and its debugger is an option, you might try the following:
Import the code into a Java project.
Ctrl-Shift-T (Open Type), enter "Thread". The binary source editor for the Thread class opens.
Select all the Thread constructors in the Outline view, use context menu "Toggle Method Breakpoint". That creates breakpoints for the constructors.
Run and debug.
Alternatively
You could get the Yourkit Java profiler, which is also available for evaluation. It can show the threads created in an application including their stack traces (also after the thread finished). It does not show where the threads were created, but the stack trace of the threads might give you some clues about the involved libraries.
JProfiler can do that. The thread monitor view shows the stack trace where a thread was created - if CPU recording was active at that time:
Disclaimer: My company develops JProfiler
In my application, some process that is started in AWT's Event Dispatching Thread (EDT) may be interrupted under particular circumstances. Then it waits for input from the user. Alas, as the process is located in the EDT, the whole application freezes and the user is unable to relaunch the process, thus creating a deadlock. Is there any way to interrupt the EDT and lauch a new event pump from another thread ? Then the user would be able to interact with the UI.
What I am trying to do looks more or less like opening a modal dialog, except that I don't want a dialog because my component is complex. I'd rather display it right inside my root pane. So I had a look at how it's done in java.awt.Dialog, and had a pretty good understanding of it, but the most important classes that are used (EventDispatchThread, SequencedEvent, ...) are protected and therefore inaccessible for me.
Thank you all for your answers.
I'll be more specific. I am actually working on an application which embeds a homegrown scripting language. I am developing a debugger for this language. The debugger (as all debuggers) would stop the script execution whenever a breakpoint is met. The scripted processes can be triggered from many places (including from the EDT) in the code so taking the the process out of the EDT is not an option. I'd like the debugger UI to be embedded in the application (in a side pane to be precise). So when a breakpoint is met I would need the current thread (possibly the EDT, not to say mainly) to be interrupted and at least the debugger's UI should still be responsive. Also I am developing atop of the JDK 1.4 so no way to use JDK7 alas.
What I am currently doing is opening a JDialog with the debugger embedded. It all works fine but as I said I am not fully satisfied by this solution because I would really want my debugger to be embedded right in my main window.
If you are using JDK7, you can use the SecondaryLoop interface. An instance of this interface can be created through the EventQueue.createSecondaryLoop method
There was an informative blog post with an example but the server seems to be offline for the moment.
A small edit as I am still not fully sure I understand your question.
If you want to wait for user input from a worker thread, you can use the SwingUtilities.invokeAndWait method and use a blocking method (e.g. show a JOptionPane to retrieve user input). Due to the invokeAndWait your worker thread will be stopped until the Runnable on the EDT is processed. If you use a blocking method on the EDT to retrieve the user input that Runnable will only be finished when the user has provided his/her input
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.
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.