xalan assertion when execution a xml query...

[Suresh Thalamati <su...@gmail.com>]

While doinng buddy testing of xml featuress, I think I gave a wrong 
xpath  and  XALAN throwed assertion to my surprise.  Not sure if it is 
some setup issue from derby side or XALAN edge case bug.  But annoying 
thing is after that query,  it gives my favorite errror "ERROR 40XT0: 
An internal error was identified by RawStore module."

is there any way to catch these assertions ?

another minor thing I noticed is errors from XALAN or nested as
"ERROR XJ001: Java exception"  it might be better to classify these 
exception under some different exception name.


FYI:
ij> SELECT i FROM t1 WHERE XMLEXISTS ('//addr*' passing by ref x);
ERROR XJ001: Java exception: 'Programmer's assertion in 
getNextStepPos: unknown
stepType: -1: java.lang.RuntimeException'.
java.lang.RuntimeException: Programmer's assertion in getNextStepPos: 
unknown st
epType: -1
         at org.apache.xpath.compiler.OpMap.getNextStepPos(OpMap.java:240)
         at 
org.apache.xpath.axes.DescendantIterator.<init>(DescendantIterator.ja



Thanks
-suresht

Re: xalan assertion when execution a xml query...

[Suresh Thalamati <su...@gmail.com>]

Army wrote:
> Army wrote:
> 
>> Given the nature of the error "Programmer's assertion in 
>> getNextStepPos", my guess is that this is a Xalan-side issue.
> 
> 
> For the record, I tried this with Xalan 2.7 and the assertion is gone; 
> in its place is a much more reasonable exception:
> 
> ij> select xmlexists('//attr*' passing by ref x) from xt_1;
> ERROR 10000: Encountered error while evaluating XML query expression for 
> XMLEXISTS operator; see next exception for details.
> ERROR XJ001: Java exception: 'A location path was expected, but the end 
> of the XPath expression was found instead.: 
> javax.xml.transform.TransformerException'.
> 
> So yes, it looks like the assertion failure is a Xalan-side issue.
> 
> Army
> 
> 

Thanks for verifying Army.

-suresh

Re: xalan assertion when execution a xml query...

[Army <qo...@gmail.com>]

Army wrote:
> Given the nature of the error "Programmer's assertion in 
> getNextStepPos", my guess is that this is a Xalan-side issue.

For the record, I tried this with Xalan 2.7 and the assertion is gone; in its 
place is a much more reasonable exception:

ij> select xmlexists('//attr*' passing by ref x) from xt_1;
ERROR 10000: Encountered error while evaluating XML query expression for 
XMLEXISTS operator; see next exception for details.
ERROR XJ001: Java exception: 'A location path was expected, but the end of the 
XPath expression was found instead.: javax.xml.transform.TransformerException'.

So yes, it looks like the assertion failure is a Xalan-side issue.

Army

Re: xalan assertion when execution a xml query...

[Army <qo...@gmail.com>]

Suresh Thalamati wrote:
> While doinng buddy testing of xml featuress, I think I gave a wrong 
> xpath  and  XALAN throwed assertion to my surprise.  

Thanks for buddy testing this, Suresh!

> Not sure if it is some setup issue from derby side or XALAN edge 
> case bug.

Given the nature of the error "Programmer's assertion in getNextStepPos", my 
guess is that this is a Xalan-side issue.  I could of course be wrong, but the 
error message and the stack trace seem to indicate that to me...

> But annoying thing is after that query,  it gives my favorite errror
> "ERROR 40XT0: An internal error was identified by RawStore module."
> 
> is there any way to catch these assertions ?

Great catch.  The code right now only catches certain Exceptions that could be 
thrown by Xalan (or JAXP) according to the APIs.  It then wraps those exceptions 
in StandardException and re-throws the StandardException.  In the example shown 
above, the error is some kind of assertion failure, not a normal Exception, and 
thus it isn't correctly caught/wrapped.  I think the best thing to do is to 
change the code to catch "Throwable" instead of Exceptions; that way any 
Throwable that is thrown by Xalan--which includes NPEs, the above assertion 
error, etc--will be caught, wrapped, and re-thrown.  The statement itself will 
still fail, but Derby as a whole should still run as normal--i.e. no "ERROR 
40XT0" stuff.

I made some quick changes in a local codeline to catch Throwable instead of 
Exceptions and that did the trick.  The query still failed with this rather odd 
assertion failure, but after the failure I could continue to execute other Derby 
statements as normal.  So that's an improvement.

I'll try to formalize this and post a patch in the next day or two.  This seems 
like something that should go into 10.2, if possible...

> another minor thing I noticed is errors from XALAN or nested as
> "ERROR XJ001: Java exception"  it might be better to classify these 
> exception under some different exception name.

When we catch a Xalan error we wrap it using the "newException()" method on 
StandardException that takes a Throwable as a parameter.  I haven't looked but 
apparently that method is what adds the "ERROR XJ001" info.  I don't know 
offhand how to best change that, but you're right, I think it'd be a good 
improvement.  That particular change may have to be a post 10.2 change, though...

Thanks again for the feedback,
Army