-
Bug
-
Resolution: Fixed
-
P3
-
1.1.4, 1.2.0
-
1.1.6
-
generic, sparc
-
solaris_2.5, solaris_2.5.1, solaris_2.6
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2016652 | 1.2.0 | J. Duke | P3 | Resolved | Fixed | 1.2beta3 |
Funtion sun_awt_motif_MFramePeer_addTextComponent() locks the AWT lock (via
AWT_LOCK) and then calls sun_awt_motif_MFramePeer_pReshape().
Function sun_awt_motif_MFramePeer_pReshape() then tries to lock the already
locked AWT lock.
If you use java_g to run the jck test harness, you get an error complaining
about this.
Our implementations of sysMonitorEnter() seem to accept the same thread
entering the monitor recursively. However, the fact that the
AWT_LOCK macro complains (in the debug version) if the lock is
acquired recursively leads me to believe that it is intended
to be acquired as a mutex (and should not be acquired recursively).
Here's the source code. The leading "**->" characters show the relevent lines
of code.
void
sun_awt_motif_MFramePeer_addTextComponent(struct Hsun_awt_motif_MFramePeer *this)
{
struct FrameData *wdata;
Classjava_awt_Frame *targetPtr;
**-> AWT_LOCK();
wdata = PDATA(FrameData,this);
if (wdata == 0 ||
wdata->winData.comp.widget==0 ||
wdata->winData.shell==0 ||
unhand(this)->target == 0) {
SignalError(0, JAVAPKG "NullPointerException", 0);
AWT_UNLOCK();
return;
}
if ( !wdata->hasIMStatusWindow ) {
wdata->hasIMStatusWindow = 1;
wdata->bottom += awt_util_getIMStatusHeight(wdata->winData.shell);
changeInsets(this, wdata);
targetPtr = unhand((struct Hjava_awt_Frame *)unhand(this)->target);
**-> sun_awt_motif_MFramePeer_pReshape(this,targetPtr->x,targetPtr->y,
targetPtr->width,targetPtr->height);
}
AWT_FLUSH_UNLOCK();
}
void
sun_awt_motif_MFramePeer_pReshape(struct Hsun_awt_motif_MFramePeer *this,
int x, int y,
int w, int h)
{
struct FrameData *wdata;
Dimension woffset, hoffset;
**-> AWT_LOCK();
Because no specific tests have been create for this fix.
This bug has been verified by executing the JCK and the current
regressioin test suite. Therefore, some exposure may exist.
- backported by
-
JDK-2016652 AWT_LOCK is recursively acquired
- Resolved
- duplicates
-
JDK-4098479 AWT lock error running Java 3D
- Closed
-
JDK-4116429 java_g AWT application causes lock errors
- Closed
-
JDK-4082547 locking assertion messages from AWT
- Closed
- relates to
-
JDK-4161354 Regression test AwtLock failing on solaris with JDK1.2fcs-C
- Closed