Skip to main content

Mustang: Swing apps freeze then painting corrupt

22 replies [Last post]
kyank
Offline
Joined: 2006-05-01
Points: 0

Is anyone else seeing this behaviour, or does a bug already exist? I'll be happy to submit a bug on this, but I don't feel like I have enough information to write a useful one.

Under Mustang b79 and b81, my Swing apps and applets are having serious issues. Often, when a repaint is required, the entire Windows system freezes for about 20 seconds, after which the application window is corrupt, but responsive (often displaying black areas, but sometimes even colourful static).

I have reproduced this with applications, webstart apps, and even applets running in Firefox.

I have *not* been able to reproduce it on a SWT application (SmartCVS). The problem does not occur on Java 1.5.x. The problem does not occur often if the system has just been started, but happens almost continually after the system has been running for a day or two.

No exceptions are thrown, but the application/applet's used heap size is always significantly smaller immediately after the hang, so it seems like the system is hanging during GC brought on by the window painting.

I don't seem to be the only one experiencing this. This report on the jEdit community forums describes exactly the effect I'm seeing, and links to a typical screenshot:

http://community.jedit.org/?q=node/view/2741

I can provide additional screenshots if required.

Windows XP SP2
ATI Radeon 9800Pro 128MB with latest official driver

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
trembovetski
Offline
Joined: 2003-12-31
Points: 0

2kyank: forgot to ask, did you get the stack trace during the hang?

Dmitri

kyank
Offline
Joined: 2006-05-01
Points: 0

Yes, I can reproduce this pretty reliably, but like nalte I have to wait until it happens (usually after a day or so of system uptime), after which I can reproduce it very readily even on new processes.

Once it happens for the first time, all I really have to do to cause it to happen again is fire up SwingSet and maximize the application window. The likelihood of a Swing app causing a freeze seems to be related to the size of that application's window (i.e. the amount of painting to be done).

No stack trace, I'm afraid. Just some pretty unremarkable-looking debug output:

D:\Program Files\Java\jdk1.6.0\demo\jfc\SwingSet2>java -jar SwingSet2.jar
[W] GetFlagValues: DDraw screen locking is disabled (W2K, XP+)
{I] InitDirectX
[V] CheckRegistry: Found Display Device 0: RADEON 9800 SERIES
{I] CreateDevice: lpGUID=0xb0c520 hMon=0x10001
{I] DDSetupDevice
{I] DDraw::CreateDDPrimarySurface: back-buffers=0
[V] DDSetupDevice: successfully created primary surface
[V] DDSetupDevice: successfully setup ddraw device

(Had to use some curly braces to avoid unwanted forum formatting)

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Thanks for the info. Another question - (I'm just trying to narrow it down to have better chance of reproducing it inhouse, so please bear with me) - so it freezes only after several days of system uptime. Do you mean that you have some java app running all this time, or do you start and quit them all the time?

Dmitri

kyank
Offline
Joined: 2006-05-01
Points: 0

Correct, the problem usually happens after at least 24 hours of uptime.

I [i]do[/i] have one Java app that I keep open most of the time, so this could well be the culprit. Closing all Java apps doesn't resolve the problem once it occurs, however -- only a reboot does that.

I'll try running that app with the noddraw flag over the next few days and will let you know if it stops the hang from occurring.

kyank
Offline
Joined: 2006-05-01
Points: 0

Reporting back.

Running the app with noddraw made no difference to the eventual appearance of the hang. After several days of uptime, I fired up another Java app (with full hardware acceleration) and the hang occurred immediately.

So the trigger seems to be system uptime, not Swing uptime.

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Hmm. Even more puzzling..

During those several days of uptime, did your system go to sleep mode multiple times, or was it up and running all the time? Or do you use hibernation?

Thanks,
Dmitri

kyank
Offline
Joined: 2006-05-01
Points: 0

It was up and running at all times. The closest my system comes to sleep mode is switching off the monitor after a period of inactivity.

nalte
Offline
Joined: 2006-02-01
Points: 0

In order to have this issue tracked officially, I have created a new bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6441744

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Thanks a lot!

Dmitri

nalte
Offline
Joined: 2006-02-01
Points: 0

I experience this problem as well.
Unfortunately, it is not really reproducible for me. Until now I had the feeling that it is related to different jvms running in parallel: e.g. IntelliJ with its private 1.5u6 and my app with the system wide 1.5u6 or 1.6b82.
The symptom for me is the very long freeze (incl. the OS (Windows XP SP2)) but with no repaint problems afterwards.
Once such a freeze happed the chance increases to see it more often (until the next reboot).

kyank
Offline
Joined: 2006-05-01
Points: 0

Just to confirm, -Dsun.java2d.noddraw=true does indeed prevent an applications from causing hangs.

kyank
Offline
Joined: 2006-05-01
Points: 0

I've successfully CPU profiled a number of these freezes, but have received very little insight into the problem.

It doesn't look like any Java code is running during the freeze. The thread runtimes captured during a ~20 second freeze only add up to about 300ms, which is just spent laying out and painting the user interface.

What else should I do to diagnose this issue?

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Could you please run java with J2D_TRACE_LEVEL environment variable set to 4 and see if you get any output during or
after the freeze? Like this:
set J2D_TRACE_LEVEL=4
java -jar SwingSet2.jar

So I take it you can reproduce the freeze pretty consistently, even with SwingSet2 and such, correct? Do you have to do something special, or does it just happen?

Thanks,
Dmitri

juerg
Offline
Joined: 2006-05-05
Points: 0

I should add that we experience just the long period while the application is frozen (20-30s). The painting afterwards is fine.

juerg
Offline
Joined: 2006-05-05
Points: 0

We experience the same problem since b77 (at least that's the build when it became appearent).
I don't think it is related to the graphics board used. We see the problem on various configurations. Although there seem to be computers on which it never happens.

The problem is intermittent but it always happens when opening the same rather complicated dialog with lots of GUI elements.

We all use Windows XP SP2.

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Thanks for the info. When this happens, does it repaint correctly eventually, or is it screwed up for the rest of the app's life? What if you resize the window?

Also, does is happen after application was idle for a while (minimized, or not in focus), or even when you were actively working with it?

Thanks,
Dmitri

kyank
Offline
Joined: 2006-05-01
Points: 0

Juerg, is it just the application that is freezing, or is it, like for me and others, a full system freeze?

For me, the corrupt areas are painted correctly when a repaint is forced (e.g. by resizing the window). Of course, doing this runs the risk of casuing the freeze-and-then-corrupt behaviour again.

As requested, I have reproduced this with the SwingSet2 demo and verbose GC. There is apparently no GC activity associated with the freezes. The amount of memory consumed by the Java process according to the Windows task manager does drop as a result of the freezes, however.

I'm endeavouring to use a profiler to determine if the process is freezing at a consistent spot in the Java code. Will report back if I have any luck.

leouser
Offline
Joined: 2005-12-12
Points: 0

can you get a snapshot of the stacks with jstack? Maybe the EDT is in deadlock at some point?

leouser

kyank
Offline
Joined: 2006-05-01
Points: 0

> can you get a snapshot of the stacks with jstack?
> Maybe the EDT is in deadlock at some point?

I can't get a snapshot during the hang, because as I said above the entire system is frozen. Even the mouse cannot be moved for a short period during the hang.

If the EDT were deadlocking, why would the hang only last 20 seconds or so?

leouser
Offline
Joined: 2005-12-12
Points: 0

weird, according to the jstack docs you should be able to do it remotely. Though you may have a better option I think it would be instructive to see where everything is stuck/spinning:
jstack [ option ] [server-id@]remote-hostname-or-IP

If the EDT was hanging it possible that you are acquiring a lock, holding it for those 20 seconds while the EDT is trying to acquire it as well. When you say that the mouse can't be moved for the period I suspect that its not a locking problem.

leouser

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Wow, this seems to be broken pretty badly. I haven't seen any reports of this.

We have this video board, I'll try to reproduce this later today. Seems like some kind of video driver issue.

Have you seen this behavior on earlier mustang builds or is it new since b79?

Could you run some application (like SwingSet2 demo) with -verbose:gc and see if the pauses could really be attributed to garbage collection.

As a workaround, you can try setting -Dsun.java2d.noddraw=true .

Thanks,
Dmitri
Java2D Team

kyank
Offline
Joined: 2006-05-01
Points: 0

I'm afraid b79 is the first Mustang release I've tried, so I can't say whether it's new or not. I suppose I could go back and try Beta 1 and some earlier snapshots if that would be useful.

I'll try the SwingSet2 demo with verbose GC and the noddraw work-around the next time my system begins exhibiting this behaviour.

Incidentally, I've now reproduced it with b82.