Do I remember you saying it works on Java 5 vm but not java 6? The only other thing I can come up with in that area is in 6 biased locking is on by default in 6 (I think). You could try turning that off, should be a very easy thing to check.
I hope you solve it, I'm really interested in finding the problem now! Grammar and spelling have been sacrificed on the altar of messaging via mobile device. On 26 Sep 2011 15:35, "Christopher Dolan" <[email protected]> wrote: > Yes, we're definitely thinking that it must be JNI-related at this point. The team is trying to reduce the problem to a simpler system now. The best bet now is that some leak on the C++ side is corrupting the Java heap. We are indeed using a third-party package for helping to bridge the Java/C++ boundary so we're inquiring there too > > Thanks for all of the feedback everyone! If we make an interesting breakthrough, I'll share the results here. > Chris > > -----Original Message----- > From: Tom Hobbs [mailto:[email protected]] > Sent: Monday, September 26, 2011 8:10 AM > To: [email protected] > Subject: Re: RE: What can cause IllegalMonitorStateException from inside a synchronized block? > > Just had a thought. Are you using any jni third party packages, or pure jni > or something swig generated? > > I ask only because I had a situation (non-river though) where a third party > tool wasn't certified for a c++ dll only c ones. After a dll upgrade the > system suddenly and strangely started to fail. We removed the jni helper > library and the problem disappeared. > > I know your situation is the other way around (I was initiating java to call > native dll) but thought it might be worth a punt. > > > > Grammar and spelling have been sacrificed on the altar of messaging via > mobile device. > > On 22 Sep 2011 16:11, "Christopher Dolan" <[email protected]> > wrote: >> Agreed, and furthermore our code is definitely not doing any weaving or > reflection skullduggery that could break that "final". >> >> No, no special GC options. Except being launched via JNI, I believe it's a > pretty straightforward JVM argument list: just classpath and a handful of > "-D" options. But I should double check that... >> >> A JIT re-ordering bug is a scary thought. I'd think that this problem > would be seen more widely if that were the case. >> >> Chris >> >> -----Original Message----- >> From: Dan Creswell [mailto:[email protected]] >> Sent: Thursday, September 22, 2011 8:54 AM >> To: [email protected] >> Subject: Re: What can cause IllegalMonitorStateException from inside a > synchronized block? >> >> final Object muxLock = new Object(); >> >> I believe that should mean muxLock cannot change.... >> >> >> On 22 September 2011 14:29, Sim IJskes - QCG <[email protected]> wrote: >>> On 22-09-11 14:38, Sim IJskes - QCG wrote: >>>> >>>> On 22-09-11 14:32, Sim IJskes - QCG wrote: >>>>> >>>>> On 22-09-11 14:04, Christopher Dolan wrote: >>>>>> >>>>>> It's quite reproducible, but only in integration not in isolation >>>>>> (yet). It was discovered as a hang in QA, then after several >>>>>> reproductions, someone attached a debugger and found that surprising >>>>>> exception. >>>>>> >>>>>> We've discovered that switching from Sun Java 1.6 back to 1.5 makes >>>>>> it go away. >>>>>> >>>>>> One noteworthy fact I've since learned (and it's obvious from the >>>>>> stacktrace in retrospect): this is a C++ thread and the root of the >>>>>> Java stack comes from C++ via JNI. In theory that shouldn't matter, >>>>>> right? But that's sure has a suspicious smell to me. >>>>> >>>>> I guess the exception is created JNI side. >>>> >>>> Are you using special garbage collector options? Can you try without? >>>> >>>> Gr. Sim >>>> >>>> >>> >>> Just to be sure. muxLock is garantueed to be constant during the > execution >>> of this code is it? No other thread assigning some other instance to it? >>> >>> Gr. Sim >>> >>> -- >>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl >>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 >>>
