WEIRD crash using Xerces-J and JNI

[Brad O'Hearne <br...@neurofire.com>]

Hey all,

I have come across a bug that has me completely stumped.  I am using Xerces
1.4.2, on Linux RH 7.1.  I have a multithreaded application, part of which
invokes a native method.  In another part of the app, I am reading a single
xml doc into a DOM.  These two parts of the app are totally unrelated, and
occur in separate threads.  The native method is written in C++, and does
absolutely nothing XML-wise -- in fact, the native library and the thread
that calls it knows nothing of Xerces.  And furthermore, the native method
is doing nothing of any major significance or complexity.  If I run
separately the thread that parses the xml doc, it works fine.  If I run
separately the thread that invokes the native method, it works fine too.
However, if I run both threads simultaneously, I crash *every time* on the
line that parses the doc into a DOM.  I totally eliminated all filesystem
IO, and hardcoded the legal xml doc as a String with the same results.  See
example below:

String s = somexml; //where somexml is a legal xml doc
InputSource is = new InputSource(new StringReader(s));
DocumentBuilder db = DocumentBuilderFactory.newInstance();
Document dom = db.parse.is(); //*** this is the line that crashes ***

...and by crashing, I don't just mean the thread hangs.  The whole thing
tanks, and brings down the VM -- no stack trace, no messages, just a bunch
of garbage blanched to the screen (i.e. memory dump).  In the code external
to Xerces, there are no resources being shared between the thread that does
this xml parsing, and the thread that invokes the JNI method.  Now here's
the kicker: I encountered this problem on jdk1.3.1, and jdk1.4beta3, and so
I decided to eliminate xerces from the mix, by just dropping it from my
CLASSPATH, and letting the compiler use the jdk1.4 javax.xml classes (which
are based on Crimson to my knowledge).  I did not change one line of code.
Both threads ran simultaneously without any problem.

I am totally stumped.  It was my understanding that Xerces was pure-Java,
but this seems to suggest otherwise, or else that Xerces is placing some
kind of hold on some system resource in the VM that JNI is trying to use.
The one thing that has been thoroughly determined, however, is that Xerces
is the culprit.  Simply include xerces.jar in my CLASSPATH, and it crashes
my program.  Remove it (without changing any code or anything else), and it
works.  Does anyone have any idea why this problem might be occurring, and
is Xerces truly pure-Java (I know the FAQ says so, but I am running out of
potential explanations for this problem).

Thanks in advance,

BradO


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org