EVALUATION
Commit to fix in Tiger (browser crash).
###@###.### 2003-10-10
Below is the stack trace :
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libX11.so.6+0x25b0c] XScreenNumberOfScreen+0xc
C [libmawt.so+0xba75] Java_sun_awt_X11_XlibWrapper_XScreenNumberOfScreen+0x29
j sun.awt.X11.XlibWrapper.XScreenNumberOfScreen(J)J+0
j sun.awt.X11.XBaseWindow.getScreenNumber()J+10
j sun.awt.X11.XBaseWindow.toGlobal(Ljava/awt/Point;)Ljava/awt/Point;+20
j sun.awt.X11.XBaseWindow.toGlobal(II)Ljava/awt/Point;+10
j sun.awt.X11.XWindow.getLocationOnScreen()Ljava/awt/Point;+3
j java.awt.Component.getLocationOnScreen_NoTreeLock()Ljava/awt/Point;+86
j java.awt.Component.getLocationOnScreen()Ljava/awt/Point;+8
j videoclipstream.run()V+506
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
###@###.### 2003-10-10
Looks like we are getting a BadWindow error when calling XGetWindowAttributes in
getScreenOfWindow (which returns a null pointer) and XScreenNumberofScreen fails. Somehow the window is bad.
###@###.### 2003-10-10
The reason why the Window is bad is because Mozilla dies and the AWT EmbeddedFrames parent is dead. So we get a BadWindow Error. To prove this,
just attach gdb to both Java and mozilla. You will see that Mozilla dies
before java does. The problem is somewhere in the browser/oji code. It causes
mozilla to crash and as a result VM to crash. Xiaobin and I debugged this and
we feel now that it is a plugin bug.
Also another proof is the bug happens both with XAWT and MAWT. So it cannot be
AWT.
Reassigning to plugin.
###@###.### 2003-10-10
The problem is the browser side work pipe does not read properly when the "read" system call fails due to "Resouce unavailable". The problem happens for this case is because the FindCookieForURL call passes a very long URL to the browser (702 character) and the read end of the pipe does not have enough buffer to process it. So "read" fails and Worker thread continues to poll the pipe and pick up the garbage which is the rest of the unread data. When the worker thread handle it to the handler code, the handler code think it is a valid command which is not.
So we should really retry to read when the error number is set to EAGAIN.
FIP.
###@###.### 2003-10-13
The bug is reproduced on Solaris9, mozilla1.4(2003/11/14)
###@###.### 2003-11-14
|
Java