|
Quick Lists
|
|
Bug ID:
|
4948258
|
|
Votes
|
0
|
|
Synopsis
|
JNI: JVM aborted with JNI Exception when (*JAWT_DrawingSurface)->Lock.
|
|
Category
|
java:classes_awt
|
|
Reported Against
|
1.3.1_02
|
|
Release Fixed
|
1.3.1_13
|
|
State
|
10-Fix Delivered,
Verified,
bug
|
|
Priority:
|
2-High
|
|
Related Bugs
|
|
|
Submit Date
|
04-NOV-2003
|
|
Description
|
An exception happens when using JNI with JDK 1.3.1.
It seems that the exception happening at (*JAWT_DrawingSurface)->Lock.
|
|
Work Around
|
N/A
|
|
Evaluation
|
For 10 mins of running the bug was reproduced with Tiger b26.
xxxxx@xxxxx 10-Oct-2003
======================================================================
Similar or related problem described at
http://support.microsoft.com/default.aspx?scid=kb;ru;315937
This may be the right solution.
xxxxx@xxxxx 12-Oct-2003
======================================================================
The problem is cused by a thread race between the TestThread and EDT.
TestThread
1. run() adds XImageBoxNative to the Container
2. Container.add() posts PaintEvent to EDT
3. removes XImageBoxNative
4. signals EDT should dispose peer native data
EDT
1. EDT disposes peer native data.
2. EDT processes PaintEvent and calls nativePaint()
3. EDT nativePaint() gets disposed peer native data through jawt
4. EDT jawt crashes !!!
Looks like a bug in jawt
======================================================================
The problem is caused by a thread race between the TestThread, EDT and
Toolkit.
TestThread
1. run() adds XImageBoxNative to the Container
2. Container.add() posts PaintEvent to EDT
3. removes XImageBoxNative
4. signals Toolkit should dispose peer native data
Toolkit
1. deletes native peer data.
EDT
1. processes PaintEvent and calls nativePaint()
2. nativePaint() calls JAWT.GetDrawingSurface()
3. JAWT.GetDrawingSurface() caches peer data
4. nativePaint() calls JAWT_DrawingSurface.Lock()
5. JAWT_DrawingSurface.Lock() tries to access cached peer data
If Toolkit.1 happens in between EDT.3 and EDT.5 jawt crashes.
There are 3 possible ways to solve the problem.
1. Synchronize access to peer data. It's impossible as we don't have
global native AWT lock. We have per object locks. But as they are
attributes of objects, event trying to get lock on deleted object
causes crash.
2. Spawn to Toolkit thread through SendMessage. Requires new event and
changes in AwtComponent::WindowProc. Also may hurt the performance.
3. Remove the jawt dependency on native peer data.
The fix seeks the third way. Jawt uses peer data for two tasks.
1. To get peer hwnd. This is solved by placing hwnd to java peer
object as long field.
2. Changing the object drawing state. Fix places the state to Window
Property instead of AwtComponent attribute.
As no sync is added the fix doesn't prevent thread race. But
replacing the dependency on natively allocated data by Win32 API and
JNI calls we ensure the race will not cause the crash.
======================================================================
Commit to tiger. We should fix this for beta2. SQE listed this as a
must-fix bug.
xxxxx@xxxxx 2003-12-16
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |