RE: [xml] NAN problems on Win32

["Vakoc, Mark" <Mark_Vakoc jdedwards com>]

>  Did you changed your compiler ? Or is that the same binary which
> fails on one system and works on others ? Do you have a way to check
> that systems have a similar setup ?

No, compiler hasn't changed, everyone gets the same binary.  I have had a
few reports of crashes of my program from various people.  Only the latest
version of my program has the crash handler that generates that log with the
stack trace, so I cannot be sure that they had the exact same problem.  If I
receive more logs I should know.   The ironic thing about your 3rd question
is that my program is a software support program that gathers information
about a clients system so we can understand what they have installed, among
other things :)  

>  First the XPath code can push the floating point/integer mix of
> instructions to the point of breaking the compiler (I happened to
> raise such a problem in gcc/i386 with it). This can also exhibit
> system/drivers bugs if FP are not saved/restored properly. And the
> last possibility is flacky hardware (or overheating which can generate
> similar hazards). The fact that NaN and infinity values can be frequently
> used by the XPath engine, while they are not common in usual code
> can also increase the probability of troubles. However they
> should not show up as indexes in a node set :-\

The pseudo-code that causes the problem looks something like like:

val = xmlXPathEval(ctxt,_X"COLSET/*"); /* _X is shorthand for BAD_CAST */
int nCols = (int) xmlXPathCastToNumber(val);

It crashes before xmlXPathCastToNumber() returns.  This happens both if val
contains nodes or is an empty node-set.  For this reason I am quite sure
that it is not NAN/INF issue directly.

One interesting note:  trionan returns different values for them as for me.
For me pinf/pinf returns NAN, whereas it returns 0 for them.

I have just sent them a debug build of libxml2, which should disable any
optimization.  I'll keep the list posted as to the results.