Saxon

Legacy ID: #4982123 Legacy Poster: Michael Kay (mhkay)

This is certainly a weird one! The fact that it's crashing on this code: if (reqItemType == null || suppliedItemType == null) { throw new NullPointerException(); } suggests strongly that it's happened before: it's the kind of code that would only be inserted so that I could put a debugger breakpoint on it. However, that doesn't help with diagnosis! I think that you're almost certainly right that some data structure is being corrupted by earlier activity: it might well be the TypeHierarchy object, which is owned by the Processor/Configuration and is probably used in computing the values of reqItemType and suppliedItemType. I suspect it's related to some very specific feature of your workload, which I'm unlikely to be able to reproduce. So if you can put together something that generates the whole workload, I'd be very grateful. It doesn't matter how complex it is, I should be able to work backwards from the crash so long as I can reproduce it. Do you do anything unusual with ClassLoaders, by any chance? Michael Kay

Legacy ID: #4987882 Legacy Poster: David Lee (daldei)

I have posted both the source and built jar's (which includes saxon) in ftp://lee.calldei.com/pub/saxon_bug there are 2 zip's and 2 gz's but you only need one set or the other. Minimally you only will need the source zip or gz but its easier to get going if you install the binaries. You should be able to build from source if needed, there is a top level 'build.xml' ant file. I have reproduced this on both windows and linux, but have only done builds on windows to date. (should build on linux though). Reproduce by extracting the non-source zip/gz+tar file and running the main test cases. To run you need to set 1 environment variable XMLSH pointing to the top level install directory, and java 1.6 in your PATH, then run xmlsh by running one the scripts in the unix/ or win32 directories There are more details if you need it on starting xmlsh at http://www.xmlsh.org/Run ... but you shoudnt need them, just run the script or see what it does, it just runs java with the classpath set right. Then run the test cases cd test ./run_tests.xsh The crash occurs on test case core/core_xexpr.xsh There is an echo line in this test right prior to the code that triggers it: # echo the following crashes saxon sometimes X=<[<foo a1='{$B}'>{$A}</foo>] You can AVOID this crash by manually running this test prior to running the test suite cd test/core ./core_xexpr.xsh cd .. ./run_tests.xsh now the system is "primed" magically and will no longer display the crash in this instance of the JVM. Note: you'll need java 1.6 or later or you'll get some error output, but it doesnt affect this test, crashes with java 1.5 as well. If you have any problems getting this up and going, or if you have any questions building or navigating the source or anything at all please let me know. I'm doing nothing special with classpaths or classloaders. -David Lee dlee@calldei.com

Legacy ID: #4988019 Legacy Poster: Michael Kay (mhkay)

Thanks. I worked out that to get xmlsh to run I needed to create a directory c:/tmp. Then I worked out (by use of xsh) that my current directory was c:/users/mike, and worked out how to navigate to the right place by an appropriate sequence of cd ../../etc. Paths starting "c:/" or "c:&quot; were rejected. Then I ran run_tests.xsh as suggested and got no crash. I got this: $ cd test $ ./run_tests.xsh running tests in core Running test core_andor.xsh Running test core_args.xsh Running test core_brace.xsh Running test core_case.xsh Running test core_for.xsh Running test core_here.xsh Running test core_if.xsh Running test core_subshell.xsh Running test core_vars.xsh Running test core_while.xsh Running test core_xexpr.xsh Differs at byte: 92 core_xexpr.xsh out/core_xexpr.xsh.out different output after exit running tests in builtin Running test builtin_colon.xsh Running test builtin_echo.xsh Running test builtin_exit.xsh Running test builtin_read.xsh Running test builtin_set.xsh Running test builtin_shift.xsh Running test builtin_source.xsh Running test builtin_xread.xsh $ That was with JDK 1.6.0_05. So I switched to JDK 1.5.0_06 and this time got the crash in typeChecker.staticTypeCheck. The challenge now will be working out how to run this in the debugger.

Legacy ID: #4988067 Legacy Poster: Michael Kay (mhkay)

OK, we're making progress. I've got it to crash in the IntelliJ debugger, which reveals that the static constant StringValue.SINGLE_SPACE has been corrupted (its typeLabel field is null). Now we've found the body, it should be a small step to find the murder weapon.

Legacy ID: #4989102 Legacy Poster: Michael Kay (mhkay)

Turns out this is essentially the bug reported by Mike Rutter: http://markmail.org/message/sbbwnyzo4o52l4c2 which I have fixed in the 9.1 branch but not in 9.0. The problem is that your first contact with Saxon is to call "new XdmAtomicValue()" and this is accessing the static variables in class BuiltInAtomicType before they are initialized by calling the static init() method. The safest workaround is to create a Saxon Configuration object (or a s9api Processor object) before you do anything else; this will cause the static initialization to be performed. I resisted retrofitting the 9.1 solution (which is adapted from Mike Rutter's proposed solution) to 9.0 because I feared it might be destabilizing. However, there seems to be a much simpler patch, which is to add the static initializer static { init(); } to class BuiltInAtomicType (and also BuiltInListType). I'll issue this as a Subversion patch.

Legacy ID: #4989521 Legacy Poster: David Lee (daldei)

Thank you ! This worked, I put new Processor(false); in the main class's static initialization block and solved the problem ! Also thank you for reporting the problems you had getting the app up and running. -David