Skip to main content

Java freezes with 1.6.0_10-ea-b07 on XP

22 replies [Last post]
qu0ll
Offline
Joined: 2006-12-09

I have just installed 1.6.0_10-ea-b07 on Windows XP and have problems with it. After a minute or so of running an applet, the Java subsystem freezes. By "Java subsystem" I mean that it's not just the applet itself but the Java Console that is freezing as well. This is with an applet that runs fine on other platforms with no freezing.

Any ideas?

--
And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jacobdk
Offline
Joined: 2008-04-21

Hi Ixmal

I have received a rather long answer from Oracle Development, which is a reply to both your comments to this thread. I am quoting what they just wrote me - I hope that you, based on this, can help getting this case moving forward somehow.

Regards,
Jacob

"First, let me reply to Sun's comment. The Sun bug 6616323 is about replacing array with a list for storing the child components of a container. It doesn't directly point to any issue related to the acquisition of tree lock in getComponentCount() method. Atleast, I don't see it. About their observation on we relying on AWT internals like representation of container's children as an array or vector, its not correct. We are not bothered about array or vector or list representation. Our concern is the additional tree lock on getComponentCount().

We want an explanation on why they added a tree lock in getComponentCount(), whereas it was not the case before. I don't know how their synchronization scheme changes with replacing a list for an array. It would be great if they don't change any external logic (acquiring a lock) due to their internal changes.

> Now SUN want to know if it is possible to have AWTTreeLock on the EWT components?

Regarding their suggested solution on our side, as I said earlier in EWT's SharedPainter we are not doing any hierarchy-sensitive "ACTIONS", we are merely traversing up the components using comp.getParent() and parent.getComponent(index), which takes care of acquiring the tree lock by itself. This is how it has been working in all JDK's till now.

Second, acquiring tree lock in our code will cause loads of deadlocks. There is a possibility that a component lock would have been grabbed before calling the painter methods shown in the thread stack and hence before grabbing the tree lock, which is opposite order from when components are validated. We already had lot of deadlocks in earlier JDKs because of this wrong order and we cannot really put a tree lock in the place they are pointing. It would require us to do lot of architectural changes to either put a tree lock and change the component lock order in lot of places where we are calling this code from.

For long time we thought that having tree lock in some of the methods in Container class like getComponents() itself was an issue with their synchronization scheme. We always believed that they should have just locked their children array/vector/list instead of the awttree."

ixmal
Offline
Joined: 2004-08-08

> "First, let me reply to Sun's comment. The Sun bug
> 6616323 is about replacing array with a list for
> storing the child components of a container. It
> doesn't directly point to any issue related to the
> acquisition of tree lock in getComponentCount()
> method. Atleast, I don't see it. About their
> observation on we relying on AWT internals like
> representation of container's children as an array or
> vector, its not correct. We are not bothered about
> array or vector or list representation. Our concern
> is the additional tree lock on getComponentCount().

Right. I've got it. I'll file a bug to remove AWT tree lock from getComponent, getComponents and getComponentCount methods and add a warning to hold AWT tree lock when calling them.

> We want an explanation on why they added a tree lock
> in getComponentCount(), whereas it was not the case
> before. I don't know how their synchronization scheme
> changes with replacing a list for an array. It would
> be great if they don't change any external logic
> (acquiring a lock) due to their internal changes.
>
> > Now SUN want to know if it is possible to have
> AWTTreeLock on the EWT components?
>
> Regarding their suggested solution on our side, as I
> said earlier in EWT's SharedPainter we are not doing
> any hierarchy-sensitive "ACTIONS", we are merely
> traversing up the components using comp.getParent()
> and parent.getComponent(index), which takes care of
> acquiring the tree lock by itself. This is how it has
> been working in all JDK's till now.

I wouldn't agree to you here. AWT tree lock must (well, not must, but should) be acquired regardless of read or read-write access to component hierarchy, in particular, when calling getParent() or getComponent().

> Second, acquiring tree lock in our code will cause
> loads of deadlocks. There is a possibility that a
> component lock would have been grabbed before calling
> the painter methods shown in the thread stack and
> hence before grabbing the tree lock, which is
> opposite order from when components are validated. We
> already had lot of deadlocks in earlier JDKs because
> of this wrong order and we cannot really put a tree
> lock in the place they are pointing. It would require
> us to do lot of architectural changes to either put a
> tree lock and change the component lock order in lot
> of places where we are calling this code from.
>
> For long time we thought that having tree lock in
> some of the methods in Container class like
> getComponents() itself was an issue with their
> synchronization scheme. We always believed that they
> should have just locked their children
> array/vector/list instead of the awttree."

This is what AWT tree lock is used for: component hierarchy access and layout operations. Please, read JavaDoc for Component#getTreeLock() method.

ixmal
Offline
Joined: 2004-08-08

> Right. I've got it. I'll file a bug to remove AWT
> tree lock from getComponent, getComponents and
> getComponentCount methods and add a warning to hold
> AWT tree lock when calling them.

The following bug is filed against AWT:

http://bugs.sun.com/view_bug.do?bug_id=6784816

It will be visible on web in a few days.

jacobdk
Offline
Joined: 2008-04-21

Great news Ixmal :)

What is the chance for 6784816 to make it into 6u12? We need 6u10+ to make an extension for our Oracle Forms system work correctly under Windows Vista, but so far, this problem has prevented us from upgrading our customers' JRE, and for that reason, the reason of this extension has been postponed.

If it's possible for you, do what you can to get this change into 6u12, please....

Regards,
Jacob

ixmal
Offline
Joined: 2004-08-08

> What is the chance for 6784816 to make it into 6u12?

6u12 has passed dev freeze, so it is very unlikely this problem will be addressed in this release.

> If it's possible for you, do what you can to get this
> change into 6u12, please....

Let me try doing this. No guarantee, though.

Artem

jacobdk
Offline
Joined: 2008-04-21

Hi Ixmal

I have got a response from Oracle Development regarding this issue. They have found, that java.awt.Container's getComponentCount() method creates a "newly added" AWTTreeLock with 1.6.0_10, and that this lock doesn't exist with any earlier JDK's. This new lock is the cause of the deadlocks occurring as earlier mentioned.

I don't have any further details at this point - I just figured, that this might also be the cause of other people experiencing similar problems. I believe Oracle will either file a bug on the JDK, or try to work around it themselves. I just want to ask, whether you can confirm this - have you heard about this before?

Regards,
Jacob

ixmal
Offline
Joined: 2004-08-08

> I have got a response from Oracle Development
> regarding this issue. They have found, that
> java.awt.Container's getComponentCount() method
> creates a "newly added" AWTTreeLock with 1.6.0_10,
> and that this lock doesn't exist with any earlier
> JDK's. This new lock is the cause of the deadlocks
> occurring as earlier mentioned.

It is the fix for 6616323 which introduced AWTTreeLock into Container.getComponentCount().

> I don't have any further details at this point - I
> just figured, that this might also be the cause of
> other people experiencing similar problems. I believe
> Oracle will either file a bug on the JDK, or try to
> work around it themselves. I just want to ask,
> whether you can confirm this - have you heard about
> this before?

No. I'm still convinced this is the problem at Oracle's side, and they shouldn't rely on AWT/Swing internals, like representation of Container's children as an array or Vector. BTW, have you received any comments from Oracle about grabbing AWTTreeLock, as I suggested?

jacobdk
Offline
Joined: 2008-04-21

Thanks again for providing some VERY useful information Ixmal. It's definitely speeding up my resolution of this issue.

> BTW, have you
> received any comments from Oracle about grabbing
> AWTTreeLock, as I suggested?

They haven't sent any comments back regarding this. I have asked the question again to those I am in contact with, and will post here as soon as I - hopefully - get a reply. I hope you will keep monitoring this thread for updates.

Jacob

kbr
Offline
Joined: 2003-06-16

Can you also install / unzip a JDK 6 and run the jstack.exe command against the process ID of your web browser?

Note that there is a new Java Plug-In implementation that will be available as an option in 1.6.0_10-ea-b08. I would very much like to know whether it addresses this and any other problems.

trembovetski
Offline
Joined: 2003-12-31

Have you experienced the lockup when running any of JDK's demos (like SwingSet)?

If so, could you get a stack trace when it hangs? (hit Ctrl+Break when the
console is in focus).

Also, please set J2D_TRACE_LEVEL env variable to 4 prior to starting
application and post the output:

[code]
set J2D_TRACE_LEVEL=4
cd jdk/demo/jfc/SwingSet2
java -jar ../../../SwingSet2.jar
[/code]

Dmitri

qu0ll
Offline
Joined: 2006-12-09

I have just tried SwingSet2 on my XP machine and I didn't experience any freezes. For me at least it's just applets that have the problem.

--
And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

trembovetski
Offline
Joined: 2003-12-31

Could you please still post the output from SwingSet2 (with the env. variable set)?

Dmitri

qu0ll
Offline
Joined: 2006-12-09

Sure, here it is. Looks like there's a problem of some kind...

[E] D3DPPLM::CheckForBadHardware: found matching bad hardware: VendorId=0x1106 DeviceId=0xffffffff
[E] D3DPPLM::GDICheckForBadHardware: all devices are bad

--
And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

trembovetski
Offline
Joined: 2003-12-31

OK, the d3d pipeline had been disabled because you have an
unsupported video board board (S3 video or a VIA
motherboard), so it doesn't look like it's the d3d pipeline that's causing your issues.

Does the jconsole application work for you?
If so, you can try to connect to a hung java process
and see the stack trace of the hang.

Thanks,
Dmitri

Message was edited by: trembovetski

qu0ll
Offline
Joined: 2006-12-09

I have never used jConsole before and I can't see how to connect to the hung applet process as there are no processes listed in the Local section.

How do I connect to a Java process running inside the browser?

--
And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

jacobdk
Offline
Joined: 2008-04-21

Oracle Forms 10.1.2.3 is hit by a very similar issue when run with 6u10 RC2 b32. When resizing the applet window, the applet will eventually freeze sooner or later. This does not happen with any other plugin but 6u10 RC2 - I have tested with 1.6.0_07 and 1.5.0_15, and it does not reproduce here.

I have recorded the hang using JConsole from JDK 1.6.0_10 RC2 b32, and it shows the following deadlock, when the hang occurs.

[code]
oracle.ewt.lwAWT.SharedPainter.add(Unknown Source)
oracle.ewt.lwAWT.BufferedFrame.addImpl(Unknown Source)
- locked java.awt.Component$AWTTreeLock@1b805ec
java.awt.Container.add(Unknown Source)
oracle.ewt.popup.PopupHandler.showProxyComponent(Unknown Source)
- locked oracle.ewt.popup.PopupHandler@8d096f
- locked java.awt.Component$AWTTreeLock@1b805ec
oracle.ewt.popup.PopupHandler.layoutContainer(Unknown Source)
java.awt.Container.layout(Unknown Source)
java.awt.Container.doLayout(Unknown Source)
oracle.ewt.lwAWT.BufferedFrame.doLayout(Unknown Source)
java.awt.Container.validateTree(Unknown Source)
oracle.ewt.swing.JBufferedFrame.validateTree(Unknown Source)
java.awt.Container.validate(Unknown Source)
- locked java.awt.Component$AWTTreeLock@1b805ec
sun.awt.windows.WComponentPeer$1.run(Unknown Source)
java.awt.event.InvocationEvent.dispatch(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)
[/code]
So far we have not been able to find a workaround for this issue, which will occur with many of our customers, if it's still present in the final 1.6.0_10. Disabling Direct3D accelleration does not help in this case. The issue is reported to Oracle Support, which has successfully reproduced the issue and logged bug 7485019, so I hope, that it can be fixed somehow.

Can you see anything from the above JConsole stack trace?

Thanks in advance,
Jacob

ixmal
Offline
Joined: 2004-08-08

I see only one thread in the stack trace, while deadlock always happens with at least two threads. Could you post or attach a full thread dump, please?

Also, I couldn't find 7485019 - is it a Sun's or Oracle's bug number?

jacobdk
Offline
Joined: 2008-04-21

Sorry, I should have made that more clear. 7485019 is an Oracle bug number, which can be looked up on MetaLink for those having paid Oracle Support, its not a Sun bug number. Since I know, that Oracle and Sun works closely together on these issues, I figured it might be relevant to post it here, since some Sun employees must have MetaLink access.

3 threads are listed in the Deadlock tab, when I provoke the hang on b32. They are as follows. I hope you can use it for something. As mentioned, this only occurs on the forthcoming 6u10.

This stack trace was generated on another system than the original stack trace I posted earlier. It looks slightly different, but the applet freezes in the exact same way...

Edit: I have just tested on 1.6.0_10 production too, released yesterday. The issue still reproduces and generates a very similar stack trace in JConsole. Hope you can help me get this problem fixed somehow...

Regards,
Jacob

[code]
Name: CursorIdler
State: BLOCKED on oracle.ewt.lwAWT.SharedPainter@128e909 owned by: Busy indicator
Total blocked: 2 Total waited: 18

Stack trace:
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.BufferedFrame.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isClippedBySibling(Unknown Source)
oracle.ewt.scrolling.scrollBox.ScrollBox.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isClippedBySibling(Unknown Source)
oracle.ewt.scrolling.scrollBox.ScrollBox.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isClippedBySibling(Unknown Source)
oracle.ewt.scrolling.scrollBox.ScrollBox.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isPaintPropagationRequired(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.paintImmediate(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.paintImmediateClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.paintImmediate(Unknown Source)
oracle.ewt.lwAWT.LWComponent.paintImmediateInterior(Unknown Source)
oracle.ewt.EwtComponent.paintImmediateCanvas(Unknown Source)
oracle.ewt.lwAWT.lwText.LWTextComponent.paintText(Unknown Source)
oracle.ewt.lwAWT.lwText.LWTextComponent.paintSelection(Unknown Source)
oracle.ewt.lwAWT.lwText.CursorIdler.run(Unknown Source)
oracle.ewt.timer.Timer.doRun(Unknown Source)
oracle.ewt.timer.Periodic.doRun(Unknown Source)
oracle.ewt.timer.Timer.run(Unknown Source)
java.lang.Thread.run(Unknown Source)

Name: Busy indicator
State: BLOCKED on java.awt.Component$AWTTreeLock@db681c owned by: AWT-EventQueue-2
Total blocked: 40 Total waited: 79

Stack trace:
java.awt.Container.countComponents(Unknown Source)
java.awt.Container.getComponentCount(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
- locked oracle.ewt.lwAWT.SharedPainter@128e909
oracle.ewt.lwAWT.BufferedFrame.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isChildClipped(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isClippedBySibling(Unknown Source)
oracle.ewt.lwAWT.LWComponent.isPaintPropagationRequired(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.paintImmediate(Unknown Source)
oracle.ewt.lwAWT.SharedPainter.paintImmediateClipped(Unknown Source)
oracle.ewt.lwAWT.LWComponent.paintImmediate(Unknown Source)
oracle.ewt.lwAWT.LWComponent.paintImmediate(Unknown Source)
oracle.forms.ui.StatsIndicator.run(Unknown Source)
oracle.ewt.timer.Timer.doRun(Unknown Source)
oracle.ewt.timer.Periodic.doRun(Unknown Source)
oracle.ewt.timer.Timer.run(Unknown Source)
java.lang.Thread.run(Unknown Source)

Name: AWT-EventQueue-2
State: BLOCKED on oracle.ewt.lwAWT.SharedPainter@128e909 owned by: Busy indicator
Total blocked: 471 Total waited: 453

Stack trace:
oracle.ewt.lwAWT.SharedPainter.remove(Unknown Source)
oracle.ewt.lwAWT.BufferedFrame.remove(Unknown Source)
- locked java.awt.Component$AWTTreeLock@db681c
java.awt.Container.remove(Unknown Source)
- locked java.awt.Component$AWTTreeLock@db681c
oracle.ewt.popup.PopupHandler._removeProxy(Unknown Source)
- locked oracle.ewt.popup.PopupHandler@1c1a68b
- locked java.awt.Component$AWTTreeLock@db681c
oracle.ewt.popup.PopupHandler.layoutContainer(Unknown Source)
java.awt.Container.layout(Unknown Source)
java.awt.Container.doLayout(Unknown Source)
oracle.ewt.lwAWT.BufferedFrame.doLayout(Unknown Source)
java.awt.Container.validateTree(Unknown Source)
oracle.ewt.swing.JBufferedFrame.validateTree(Unknown Source)
java.awt.Container.validate(Unknown Source)
- locked java.awt.Component$AWTTreeLock@db681c
sun.awt.windows.WComponentPeer$1.run(Unknown Source)
java.awt.event.InvocationEvent.dispatch(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)
[/code]

ixmal
Offline
Joined: 2004-08-08

The deadlock actually happens between two threads: "AWT-EventQueue-2" which is applet's EDT and "Busy indicator". My guess is that this problem is just Oracle's bug: they perform some hierarchy-sensitive actions (see "Busy indicator" stack staring from oracle.ewt.lwAWT.LWComponent.paintImmediate) without holding AWT tree lock. If this lock is acquired at the beginning of child/sibling traversal (and before locking SharedPainter object), the deadlock wouldn't happen.

As for running with JDK versions prior to 6u10 - as with any threading issue, the problem may just be unreproducible due to the lucky timings. At least, I don't remember any changes in 6u10 in AWT area related to using the tree lock.

jacobdk
Offline
Joined: 2008-04-21

Hi Ixmal

Thanks for this very useful response. I have forwarded your response to Oracle's bug screening department, currently awaiting their response to this issue - which really is a showstopper for us to deploy JRE 1.6.0_10 for our Forms apps. I will update this thread, if/when I get a response from them.

Thanks,
Jacob

swpalmer
Offline
Joined: 2003-06-10

I experienced lock-ups when resizing the window for my Swing application. I think it may be related to work on the graphics pipeline.

qu0ll
Offline
Joined: 2006-12-09

I can't comment on that as I have only used the latest release for non-Swing applets.

--
And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)