EVALUATION
Note that it appears that 2D doesn't use the native peer data correctly,
at least, on windows.
Prior to getting the pData we should first obtain a global
lock, otherwise other thread may dispose the native component's data.
In Win32SurfaceData_GetWindow() we call Win32SurfaceData_GetComp()
which retrieves a pointer to AwtComponent from the peer object,
and this pointer is then used to get the insets. A thread
could dispose the native data at any time since we don't
hold any locks, and we'll die when dereferencing.
|
|
|
EVALUATION
I believe the bug is fixed with my change in WComponentPeer.
The change is a part of the fix for 6255371. The change
is to post an invocation event (which replaces the surface
data associated with the component) to the event dispatch thread
of the app context, to which the current component belongs.
Previously all such invocation events were posted to the event
dispatch thread of the main app context and a thread race
might result in NullPointerException.
Note the bug is not easily reproducible, so I can't verify
whether it's fixed. The bug may be closed if it is not
reproducible any more.
|
|
|
EVALUATION
I don't have a dual CPU machine any more and it's therefore very hard to see if this is gone. Does anyone else have a machine to test this out on?
|
|
|
EVALUATION
The bug is reproducible all the way since b18 (don't have
the earlier builds handy), but not on 1.4.2, as far as I can tell.
Also, I've only been able to reproduce it on Windows dual-cpu systems
(I've reproduced it on both windows-i586 and windows-amd64).
I wouldn't call it a tiger showstopper, as the exception seems to be
harmless - we detect a null data pointer and throw the exception.
It's possible that applets running in browser can throw
it as well when the user leaves the page - I haven't tried this
yet.
###@###.### 2004-06-17
|
|
|
|
Java