JDK-6342381 : NetBeans GUI causes crash in b57
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic,x86
  • Submitted: 2005-10-27
  • Updated: 2015-07-17
  • Resolved: 2005-12-17
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.
JDK 6
6 b65Fixed
Related Reports
Duplicate :  
JDK-6344815 - crash with NB5.0 in Java_sun_java2d_loops_MaskBlit_MaskBlit+0x269
Duplicate :  
JDK-6344823 - crash with NB5.0 in Java_java_util_zip_ZipFile_freeEntry+0x26
Duplicate :  
JDK-6344820 - crash with NB5.0 in [libjvm.so+0x3ef66a]
Relates :  
JDK-6351153 - Refactor SunDropTargetContextPeer and its nested class EventDispatcher
Relates :  
JDK-6373059 - OutOfMemoryError on ZipFile.open
Relates :  
JDK-8041519 - JVM crash on second DnD after modal dialog opened during Swing DnD operation
Description
NetBeans crashes hotspot when I drag a frame to rearrange the layout
but hits escape before dropping the frame.

The problem always happens on first try if I use server or client VM.
If I use -Xint, I have to try a few times before the problem occurs.

I can *not* reproduce the problem on b30 or 1.5.0_06-b03.

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0x00945dfb, pid=5893, tid=3037801392
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-ea-b57 mixed mode, sharing)
# Problematic frame:
# C  [libc.so.6+0x60dfb]
#
# An error report file with more information is saved as hs_err_pid5893.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Comments
SUGGESTED FIX Looks like the suggested fix cannot affect WToolkit because of we do not manage memory allocation on WToolkit in this case using Unsafe class. On XToolkit we use Unsafe.allocateMemory(long bytes) to keep XClientMessageEvent structure. On WToolkit we use AwtDropTarget as native drop target context. We release its reference properly in native code after removeNotify invocation on DropTarget in java code. As to MToolkit its implementation is similar to XToolkit. Except the fact that we keep flag dispatcherDone in native code. It possible that we could move it into java code but it could bring us to regressions.
11-11-2005
SUGGESTED FIX SunDropTargetContextPeer.nativeDragContext isn't nullified just after all SunDropTargetEvents that are associated with this nativeDragContext are processed. This fact together with the Netbeans issue 43059 [Gnome] Escape key does not work as expected when dragging a window (http://www.netbeans.org/issues/show_bug.cgi?id=43059) seems to cause double freeing of the memory allocated for the nativeDragContext. The following change should fix the crash on the AWT side: --- SunDropTargetContextPeer.java Thu Nov 10 18:09:25 2005 *************** *** 858,864 **** * the original event are processed. */ if (dispatcherDone) { ! nativeCtxt = 0; } } } --- 858,864 ---- * the original event are processed. */ if (dispatcherDone) { ! peer.nativeDragContext = 0; } } } *** (#1 of 1): [ UNSAVED ] ###@###.###
10-11-2005
EVALUATION We recieve the same SunDropTargetEvent twice. At the moment I cannot unambiguously say why this occurs. It could be considered with netbeans dnd implementation or Xlib. I look closely at NetBeans implementation.
10-11-2005
EVALUATION I could reproduce the problem on SuSE 9.2 with GNOME, JDS on linux, GNOME on RHAS (using Reflection X). I used 6.0 build 35, 6.0 build 58. I could not reproduce the problem on solaris with JDS at all and I could not reproduce it with builds junior than b35 and Tiger. I noticed that NetBeans use drag and drop in some unusual way. It occurs when the bug is not reproducible. If I press "ESC" key mouse pointer is changed to usual pointer but drag happens. This behaviour differs from native. So I tried to reproduce the same problem using SwingSet2 from Demo packages. In usual swing application if user press "ESC" during drag operation drag operation is canceled completely. Could you provide more simple testcase which could reproduce the problem? Or could you point out how implemented drag and drop of panels in NetBeans?
09-11-2005
EVALUATION After some time of debugging Java process used to launch NetBeans it has appeared that the problem is most probably in XDropTargetContextPeer.eventProcessed() method. It contains try-finally block and a call to Unsafe.freeMemory() under 'finally' statement. The check 'cntx != 0' is performed, but this is not enough as the memory addressed by this field may be already freed from other (native?) code.
08-11-2005
EVALUATION Concerning Motif. The only log that contain motif-related information is about sun.dc.pr... Not sure what is it but it used by 2d DuctusShapeRenderer.
31-10-2005
EVALUATION There are a lot of different logs attached. I tried to classify problems from them into several groups: -- 1) WWindowPeer.nativeGrab() - hs_err_pig3196.log is actually look like a dup of 6328661. It's being fixed in Mustang RC. This is the reason why it's still exist in b55. -- 2) libc crash after call from ClassLoader (pid10689) C [libc.so.6+0x61670] C [libc.so.6+0x60e6a] C [libc.so.6+0x6025d] malloc+0x8d C [libjava.so+0xb3d3] Java_java_lang_ClassLoader_defineClass1+0x43 J java.lang.ClassLoader.defineClass1(Ljava/lang/String;[BIILjava/security/ProtectionDomain;Ljava/lang/String;)Ljava/lang/Class; J java.lang.ClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/ProtectionDomain;)Ljava/lang/Class; J org.netbeans.JarClassLoader.simpleFindClass(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Class; -- 3) libdcpr.so crash: (pid689) C [libdcpr.so+0x2529] C [libdcpr.so+0xb1c4] C [libdcpr.so+0x4663] Java_sun_dc_pr_PathFiller_reset+0x43 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J sun.dc.pr.PathFiller.reset()V J sun.java2d.pipe.DuctusShapeRenderer.renderPath(Lsun/java2d/SunGraphics2D;Ljava/awt/Shape;Ljava/awt/BasicStroke;)V -- 4) jvm crash (29485): -- 5) libGL (pid4874) -- 6) libc (pid5893) Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc.so.6+0x60dfb] C [libc.so.6+0x6025d] malloc+0x8d V [libjvm.so+0x2c7d7a] V [libjvm.so+0x3545cf] j sun.misc.Unsafe.allocateMemory(J)J+0 j sun.awt.X11.XDnDDropTargetProtocol.notifyProtocolListener(Lsun/awt/X11/XWindow;IIILsun/awt/X11/XClientMessageEvent;I)V+35 j sun.awt.X11.XDnDDropTargetProtocol.processXdndPosition(Lsun/awt/X11/XClientMessageEvent;)Z+290 AWT affected by them in 1 and 6 cases only. 1 most possibly is not reproducible anymore. 6 shows the crash through jvm calls so it's unlikely AWT bug. Interestin that enabling MToolkit uncover problem with JDK5.0.
31-10-2005