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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
