Bug ID: JDK-4297157 VM Crash with Remote Menus

Type: Bug
Component: client-libs
Sub-Component: 2d
Affected Version: 1.3.0

Priority: P2
Status: Resolved
Resolution: Fixed
OS: solaris_7
CPU: sparc

Submitted: 1999-12-06
Updated: 1999-12-11
Resolved: 1999-12-11

Other
1.3.0 kestrelFixed

I've been doing some work to improve Swing's performance on remote X and I've been running into trouble with HotSpot crashing.  Here are the steps to reproduce:

There is a jar file at: /home/wilsonsd/SheetMetalScroll.jar

I'm running with the following build (from usr/local/java/jdk1.3):

java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-P)
Java HotSpot(TM) Client VM (build 1.3-P, interpreted mode)

Everything works fine when I'm running locally, but if I run the app on another machine via Remote X, and use the menus, I get the following VM error:


# HotSpot Virtual Machine Error, Unexpected Signal 10
#
# Error ID: 4F533F534F4C415249530E43505007B5 01
#

Let me know if you need more help reproducing it.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kestrel FIXED IN: kestrel INTEGRATED IN: kestrel

14-06-2004

SUGGESTED FIX Name: vuC71690 Date: 12/10/99 ###@###.### 1999-12-10 With this fix the crash goes away. XDestroyRegion simply frees the region data, so keeping a dangling pointer to that freed memory is a bad idea. *** src/solaris/native/sun/awt/awt_Graphics.c~ Fri Dec 10 16:59:11 1999 --- src/solaris/native/sun/awt/awt_Graphics.c Fri Dec 10 16:50:21 1999 *************** *** 2116,2121 **** --- 2116,2122 ---- if (pScreen->region != NULL) { XSetClipMask(awt_display, gdata->gc, None); XDestroyRegion(pScreen->region); + pScreen->region = NULL; } ret = sun_awt_motif_X11Graphics_UNLOCK_OK; } *************** *** 2605,2610 **** --- 2606,2612 ---- if (pScreen->region != NULL) { XSetClipMask(awt_display, gdata->gc, None); XDestroyRegion(pScreen->region); + pScreen->region = NULL; } if (img != gdata->monoImage) { XDestroyImage(img); ======================================================================

11-06-2004

EVALUATION The HotSpot message is just HotSpot's way of reporting a bus error; from the description (remote versus local display triggers the crash), this has to be an AWT/swing (Motif?) problem. ------------------------- I had Hans Muller look at this example. Here is his reply: Although I noticed that scrolling performance was noticeably better with the 'buffer off + old scroll mode' version of the app; entering items into the spreadsheet didn't feel too much different. Unfortunately, the app showed loads of small painting errors: single pixels dropped out here and there and there was an unpleasant rectangle next to the "Exit" menu item. I didn't see the paint problems with either version of the app when I ran it locally. Also: I didn't get any crashes from using the menus. ----------------------------------------- Has isn't seeing the VM crash, but is seeing graphics corruptions. That makes me think that there is some kind buffer overflow, or perhaps a dead C pointer involved. My guess is that some memory is being corrupted and this is causing the VM to crash on my machine, but is causing painting problem's on Hans'. steve.wilson@Eng 1999-12-07 Name: vuC71690 Date: 12/09/99 ###@###.### 1999-12-09 This seems like 2D problem. The crash happens when menu that is dropped down has a menu item with an image. Essential info from the dbx session follows: (dbx) run -jar SheetMetalScroll.jar t@8 (l@3) signal SEGV (no mapping at the fault address) in _free_unlocked Current function is Java_sun_awt_motif_X11Graphics_X11putMonoImageData 2607 XDestroyRegion(pScreen->region); (dbx) where [1] _free_unlocked(0x6c00ee00) [2] free(0x6c00ee00) [3] XDestroyRegion() =>[4] Java_sun_awt_motif_X11Graphics_X11putMonoImageData(), line 2607 in "awt_Graphics.c" (dbx) print *pScreen *pScreen = { int method = METHOD_TMP_XIMAGE XImage screenBits = 0x5e97a8 # uwe: content seems ok Region region = 0x5dc030 int fUsingRegion = 1 GraphicsData *gdata = 0x5e9638 # uwe: content seems ok int locked = 1 } # uwe: Type `Region' is opaque for client code. # This is the definition from Xlib internals. # # typedef struct { # short x1, x2, y1, y2; # } Box, BOX, BoxRec, *BoxPtr; # # typedef struct _XRegion { # long size; # long numRects; # BOX *rects; # BOX extents; # } REGION; # Examine the pScreen->region. Some garbage here, not even # remotely resembling anything that could be meaningfully # interpreted as the above structure. free() that crashes was # invoked upon the Box *rects field. (dbx) x 0x5dc030/8X 0x005dc030: 0x005dbfe8 0x6c006c00 0x6c00ee00 0x6c002d03 ^-----size ^-numRects ^----rects 0x005dc040: 0x6c002d03 0xee000000 0x00000018 0x00000000 The crash manifests with both classic and hotspot. ====================================================================== Name: vuC71690 Date: 12/10/99 ###@###.### 1999-12-10 XDestroyRegion simply frees the region data, so keeping a dangling pointer to that freed memory is a bad idea. This fix also seems to fix the 4288819, "Segmentation fault occurs in TicTacToe's applet save on Solaris", which we propose to recategorize against 2D as well. ====================================================================== Uwe is correct. The problem was with the region variable not being reinitialized when the region was destroyed. jeannette.hung@Eng 1999-12-10

10-12-1999