|
Description
|
One of the way to see whether it is caused by Plug-in or not is to run "appletviewer". If we can also reproduce there, it is either the user's code problem or AWT issue.
xxxxx@xxxxx 2003-12-12
The above summary is not correct. Just because a bug is not caused by the
plugin does not automatically mean it belongs to AWT. If the plugin team
believes it is not a plugin problem, they should try to determine the correct
category based on the results of a thorough and careful investigation.
xxxxx@xxxxx 2003-12-12this bug is to track and create an escalation for case 63786394
all stack traces, dumps, etc. can be located from the case notes
xxxxx@xxxxx 2003-12-12
some customer detail about showrev output
I have looked into the showrev -p output and I found that they are upto date in the patches.
Following patch is missing, but I do not think this is relevant...
112003-03 SunOS 5.8: Unable to load fontset in 64-bit Solaris 8 iso-1 or iso-15
They do not have 111310-01 and 111111-03 patches but have 108528-21 which obsoletes both (111310-01, 111111-03) these patches.
They do not have 111023- customer patch but have 108993-18 which obsoletes this(111023- customer ) patch.
They have 108993-29 version of the patch while the recommended is 108993-26
*108993-26 SunOS 5.8: LDAP2 client, libc, libthread and libnsl libraries patch
They have 108528-24 while the recommended is 108528-25
*108528-25 SunOS 5.8: kernel update patch
xxxxx@xxxxx 2003-12-12
another update ... some of the commented out code
I am quite certain you aren't directly using JNI in the application and feel the mention of JNI in the stack trace is due to the AWT components. I was hoping to document as part of the case.
When the pack() method is invoked it attempts to calculate the size of every child component. I am trying to understand where the Component$AWTTreeLock is called as part of the pack().
I will look at the stack dump with this code snippet.
Thank you.
Z.
Chris Zupko
---- "Ferdinand, Lori Beth (Lori)" < xxxxx@xxxxx > wrote:
> Chris,
>
> Here is the code from the SaveDialog class: (line 81 is the pack() call near the end)
>
> /** private members */
> private JPanel filterPanel = null;
> private JPanel savePanel = null;
> private SaveFileChooser chooser = null;
> private JSeparator separator = null;
> private Dimension dm = null;
> private Container contentPane = null;
>
> private static int count = 0;
> private static int height = 0;
> private int showCount = 0;
> private FullPage fullPg = null;
>
> /**
> * Default constructor made private, so that no user of this class can
> * make a direct call it, since it is not intended to be used.
> */
> private SaveDialog() {;}
>
> public SaveDialog(FullPage Page, JPanel leftPanel, SaveFileChooser fileChooser)
> {
> super();
> Tracer.output(Constants.SAVE, 5, "SaveDialog()");
> this.fullPg = Page;
> addComponentListener(this);
> filterPanel = leftPanel;
> chooser = fileChooser;
> String rsrcBndle = null;
> rsrcBndle = fullPg.getPageResource("SaveButton.ItemDesc");
> if(rsrcBndle == null) {
> rsrcBndle = "Save";
> }
> setTitle(rsrcBndle);
> contentPane = this.getContentPane();
> contentPane.setLayout(new FlowLayout());
> buildFilterPanel();
>
> //force a horizontal space between the filter area and the separator bar
> contentPane.add(Box.createHorizontalStrut(5));
>
> separator = new JSeparator(JSeparator.VERTICAL);
> dm = separator.getPreferredSize();
> contentPane.add(separator);
>
> //force a horizontal space between the separator bar and the filechooser
> contentPane.add(Box.createHorizontalStrut(5));
>
> buildSavePanel();
> this.pack();
> setResizable(false);
> }
>
> /**
> * Add a filter area that allows the user to restrict the data to be saved.
> */
> private void buildFilterPanel() {
> Tracer.output(Constants.SAVE, 5, "SaveDialog.buildFilterPanel()");
> this.contentPane.add(filterPanel);
> }
>
> /**
> * Create a panel to hold the SaveFileChooser customer
> */
> private void buildSavePanel() {
> Tracer.output(Constants.SAVE, 5, "SaveDialog.buildSavePanel()");
> this.savePanel = new JPanel();
> this.savePanel.add(chooser);
> this.contentPane.add(savePanel);
> }
>
> Lori
>
> -----Original Message-----
> From: Chris Zupko [mailto: xxxxx@xxxxx ]
> Sent: Wednesday, December 10, 2003 10:03 PM
> To: Vijay Kaza; Ferdinand, Lori Beth (Lori)
> Cc: ' xxxxx@xxxxx '; ' xxxxx@xxxxx '; ' xxxxx@xxxxx '; Kunkel, Ronald Dale (Ron); Kumar, Ajoy (Ajoy); 'Al Palleschi'; ' xxxxx@xxxxx '
> Subject: Re: Sun case 63786394 Netscape hang
>
> You may have already discussed this, but why does JNI appear to be used in one of the deadlocked threads?
>
> Is JNI being used in the application? If so, for what reason?
>
> I am concerned about the tree component after looking at the 1st two thread dumps. Let me do a little research. Besides the question about JNI, would you please let me see the code with line numbers surrounding lucent.fm.parts.SaveDialog.<init>(SaveDialog.java:81)? If it's a small method could you provide the entire init method/block?
>
>
>
> Thanks,
> -
>
> Z.
> Chris Zupko
>
>
> ---- Vijay Kaza < xxxxx@xxxxx > wrote:
> > Hi Lori,
> >
> > These kill -3 outputs look different from the ones that we have seen earlier. In these thread dumps 2 are identical while the third one is different and all of the stacktraces are showing a Java Level Deadlock which was not the case earlier.
> > It seems like the thread dump / stacktrace might change based on when we resize the window.
> >
> > Thanks,
> > -Vijay
> >
> > "Ferdinand, Lori Beth (Lori)" wrote:
> >
> > > All,
> > >
> > > Here are the thread dumps for three more times I was able to get the browser window to hang. For the first two dumps I followed the exact same scenario as yesterday (one Netscape window & resizing while it is attempting to initialize the JTable) and the files appear to be very similar to the vm.notitle.120903 file I sent previously. The third dump (vm.out.12100303), however, represents a slightly different scenario (one Netscape window & resizing it at a different place in the application before it attempts to initialize the JTable) and the data, therefore, looks different as well.
> > >
> > > Lori
> > >
> > > <<vm.out.12100301>> <<vm.out.12100302>> <<vm.out.12100303>>
> > > -----Original Message-----
> > > From: Ferdinand, Lori Beth (Lori)
> > > Sent: Wednesday, December 10, 2003 3:56 PM
> > > To: ' xxxxx@xxxxx '; ' xxxxx@xxxxx '; ' xxxxx@xxxxx '; ' xxxxx@xxxxx '
> > > Cc: Kunkel, Ronald Dale (Ron); Kumar, Ajoy (Ajoy); 'Al Palleschi'; ' xxxxx@xxxxx '
> > > Subject: RE: Sun case 63786394 Netscape hang
> > >
> > > All,
> > >
> > > Here is the code segment which represents what we have commented out in the latest patch we sent to Verizon:
> > >
> > > public void setBrowserTitle(String title) {
> > > JSObject js = JSObject.getWindow(OneUIUtilities.getApplet(FullPage.this));
> > > JSObject doc = (JSObject)js.getMember("document");
> > > String setTitleStr = "document.title='" + title + "'"; js.eval(setTitleStr);
> > > }
> > >
> > > public class OneUIUtilities extends Object {
> > >
> > > /**
> > > * Find the Applet in the ancestry of <tt>c</tt>. If none can
> > > * be found, returns null.
> > > */
> > > public static final Applet getApplet(Component c) {
> > > Applet a = null;
> > > while ( ! ( c instanceof Applet ) && (c != null)) {
> > > c = c.getParent();
> > > }
> > > if ( c != null ) {
> > > a = (Applet)c; return(a);
> > > }
> > > return null;
> > > }
> > >
> > > ...
> > > }
|
|
Evaluation
|
A little more detailed info. based on the stack dump:
AWT-EventQueue-0 thread:
holding AWTTreeLock at java.awt.Component.reshape
waiting for AWT_LOCK at Java_sun_awt_motif_MWindowPeer_getState of awt_TopLevel.c
main thread:
waiting for AWTTreeLock at java.awt.Window.getGraphicsConfiguration
holding AWT_LOCK at JNICALL Java_sun_awt_motif_MComponentPeer_pInitialize of awt_Component.c
xxxxx@xxxxx 2003-12-12
There is the problem. You must get the treelock first,then the AWT_LOCK.
BTW, it looks like the 2D team fixed this in Merlin.
Here is a possible solution: in awt_Component.c (from 1.3.1_09)
the code looks like this
JNIEXPORT void JNICALL Java_sun_awt_motif_MComponentPeer_pInitialize
(JNIEnv *env, jobject this)
{
struct ComponentData *cdata;
Widget parent;
jobject target;
jobject globalRef;
EventMask xtMask;
long awtMask = 0;
AwtGraphicsConfigDataPtr adata;
globalRef = (jobject)
JNU_GetLongFieldAsPtr(env, this, mComponentPeerIDs.jniGlobalRef);
AWT_LOCK();
adata = copyGraphicsConfigToPeer(env, this);
target = (*env)->GetObjectField(env, this, mComponentPeerIDs.target);
copyGraphicsConfigToPeer gets the treelock.
One solution might be to move the call to copyGraphicsConfigToPeer
immediately before the call to AWT_LOCK(), thus avoiding the deadlock.
That's what the code looks like in Tiger.
xxxxx@xxxxx 2003-12-12
|
