JDK-6205496 : Crash in GrPrim_CompGetXorInfo when running MTGraphicsAccessTest -full
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0,6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2004-12-08
  • Updated: 2012-01-16
Related Reports
Relates :  
Description
During the investigation of 5089429 we've run into another problem caused by
mutlithread access to a Graphics object.
Run test/java/awt/Graphics2D/MTGraphicsAccessTest with -full parameter
(a multiple-cpu system is preferred), on a jdk with fixed 5089429 and the 
following crash may occur:
current thread: t@33
  [1] _lwp_kill(0x0, 0x6, 0x0, 0xff33c000, 0x0, 0x0), at 0xff31e42c 
  [2] raise(0x6, 0x0, 0xd3efed48, 0x7efefeff, 0x81010100, 0xff00), at 0xff2ccd70 
  [3] abort(0xd3efedf0, 0xfec9c756, 0xfec9c753, 0x21, 0x81010100, 0xff00), at 0xff2b5c60 
  [4] os::abort(0x1, 0xfed2c25c, 0x7d0, 0xfee53078, 0x0, 0x0), at 0xfe77af28 
  [5] VMError::report_and_die(0xd3efefc8, 0x20caa8, 0xfebe862e, 0xfebe85f8, 0x4f, 0x0), at 0xfea702a8 
  [6] report_fatal(0xfebe85f8, 0x4f, 0xfebe862e, 0x148b, 0x9c2db90, 0xd3eff450), at 0xfe1708f0 
  [7] jfieldIDWorkaround::verify_instance_jfieldID(0xd619ce50, 0xf9328833, 0x4, 0xfa8294a0, 0x25c, 0xd3eff4e0), at 0xfe397c38 
  [8] jfieldIDWorkaround::from_instance_jfieldID(0xd619ce50, 0xf9328833, 0x4, 0xfa829060, 0xefa5ec78, 0xd3eff588), at 0xfe3d398c 
  [9] jni_GetIntField(0x20cb74, 0x2129e4, 0xf9328833, 0xfa8297c0, 0xefa5ec78, 0xd3eff620), at 0xfe3b6fe0 
=>[10] GrPrim_CompGetXorInfo(env = 0x20cb74, pCompInfo = 0xd3eff2ac, comp = 0x2129e4), line 438 in "GraphicsPrimitiveMgr.c"
  [11] GrPrim_Sg2dGetCompInfo(env = 0x20cb74, sg2d = 0xd3eff4c0, pPrim = 0xd5d2f710, pCompInfo = 0xd3eff2ac), line 390 in "GraphicsPrimitiveMgr.c"
  [12] Java_sun_java2d_loops_FillSpans_FillSpans(env = 0x20cb74, self = 0xd3eff4c4, sg2d = 0xd3eff4c0, sData = 0xd3eff4bc, pixel = 2139094784, pIterator = -707586392LL, si = 0xd3eff4ac), line 44 in "FillSpans.c"

  It looks like we started rendering in xor mode, but the sg2d.composite
  got changed by another thread before we pulled it from the native code,
  so we then attempted to get the xor pixel color from a different
  composite..

###@###.### 2004-12-08 00:20:48 GMT

Comments
EVALUATION We could check the instance of the comp object before retrieving the xor pixel. This will avoid an immediate crash, but further recovery is not clear. We could throw an internal error indicating that the graphics object is in the wrong state. The same should be probably be done for GrPrim_CompGetAlphaInfo: the composite could have changed to xor before we got to the native code. One thing is that adding the instanceof check would probably slow down the common case, which is unfortunate.
04-08-2005

EVALUATION As per description. ###@###.### 2004-12-08 00:20:49 GMT
08-12-2004