On 9/22/2011 8:54 AM, Dan Creswell wrote:
final Object muxLock = new Object();
I believe that should mean muxLock cannot change....
For Java code, compiled in the same compile, with visibility of that definition,
that would be the obvious decision. I do wonder if there is something in the
JNI code that is not going "quite right." I did add calls to lock and unlock
Java object in some JNI code once, and I seem to remember seeing this kind of
error as well. I just do not recall enough of those moments to correlate what
really happened and what I had to fix.
If the JNI code sees or uses muxlock, and in particular, can "lock" mux lock,
check to make sure that there is matching lock and unlock sequences in the JNI code.
Gregg Wonderly
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
