JDK-4935740 : Mozilla 1.4 Mecury build_09 crash when visit http://www.clipstream.com
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2,1.4.2_01
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,linux_suse_sles_8.2
  • CPU: x86
  • Submitted: 2003-10-10
  • Updated: 2004-10-15
  • Resolved: 2004-10-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2_04 04Fixed
Related Reports
Duplicate :  
JDK-4937393 - plugin crashes Netscape with secure internet banking
Description
Reproduce steps:
1.On Mecury_09, mozilla1.4(2003/9/19), JRE1.4.2_01
2.Start mozilla and visit http://www.clipstream.com. After a while, mozilla will crash.
3. On terminal, "INTERNAL ERROR on Browser End: Plugin instance index out of bounds 12870
System error?::Interrupted system call" was displayed.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_04 tiger tiger-beta FIXED IN: 1.4.2_04 tiger tiger-beta INTEGRATED IN: 1.4.2_04 tiger tiger-b26 VERIFIED IN: 1.4.2_04
14-06-2004
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
13-10-2003