Stopping the evaluation of an XQuery in .NET

[Kashmulik]

Hi,

I use Saxon library for .NET to evaluate XQueries. Is there a way to stop the Evaluation after it was started? Can I limit the run time of the XQuery to 10 seconds for handling a case that an infinitely recursive XQuery was entered? Is there a way to avoid infinitely recursive XQueries from Running? How can I handle the "stack overflow" exception that they throw?

thnx!

[Michael Kay]

There's nothing built into the product for this. You could write a
TraceListener and monitor execution from there, but it would slow down the
query execution significantly. You might be better doing something at the
operating system level - I don't know enough about the .NET threading model
to know what is possible.

You can catch a StackOverflow exception in Java, but I'm not sure whether
you can do so on .NET.

Michael Kay
http://www.saxonica.com/

> -----Original Message-----
> From: saxon-help-bounces@...
> [mailto:saxon-help-bounces@...] On Behalf
> Of Kashmulik
> Sent: 13 July 2008 18:23
> To: saxon-help@...
> Subject: [saxon] Stopping the evaluation of an XQuery in .NET
>
>
> Hi,
>
> I use Saxon library for .NET to evaluate XQueries. Is there a
> way to stop the Evaluation after it was started? Can I limit
> the run time of the XQuery to 10 seconds for handling a case
> that an infinitely recursive XQuery was entered? Is there a
> way to avoid infinitely recursive XQueries from Running?
> How can I handle the "stack overflow" exception that they throw?
>
> thnx!
> --
> View this message in context:
> http://www.nabble.com/Stopping-the-evaluation-of-an-XQuery-in-
> .NET-tp18431522p18431522.html
> Sent from the saxon-help mailing list archive at Nabble.com.
>
>
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK &
> win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Abel Braaksma (online)]

Michael Kay wrote:
> You can catch a StackOverflow exception in Java, but I'm not sure whether
> you can do so on .NET.
>
>  

Hi Michael,

On .NET it is far from trivial to catch a StackOverflowException,
because Microsoft discouraged it by making it hard in prior-to-.net-2.0
versions. From .Net 2.0 onwards it is impossible, but you can create an
application domain and let that crash instead of your whole application.

From:
http://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspx
In prior versions of the .NET Framework, your application could catch a
StackOverflowException object (for example, to recover from unbounded
recursion). However, that practice is currently discouraged because
significant additional code is required to reliably catch a stack
overflow exception and continue program execution.

Starting with the .NET Framework version 2.0, a StackOverflowException
object cannot be caught by a try-catch block and the corresponding
process is terminated by default. Consequently, users are advised to
write their code to detect and prevent a stack overflow. For example, if
your application depends on recursion, use a counter or a state
condition to terminate the recursive loop. Note that an application that
hosts the common language runtime (CLR) can specify that the CLR unload
the application domain where the stack overflow exception occurs and let
the corresponding process continue.

Cheers,
-- Abel --

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Michael Kay]

Thanks for this info.

The other relevant point, of course, is that if your "infinite recursion"
involves a tail-call, then you won't get a stack overflow exception anyway;
instead you will get an infinite loop.

Perhaps I need to add an option to limit the recursive depth at the Saxon
level. I can't say I'm enthusiastic about this: (a) it involves a run-time
cost, and (b) 99.99% of users won't know how to set it correctly.

Michael Kay
http://www.saxonica.com/

> -----Original Message-----
> From: saxon-help-bounces@...
> [mailto:saxon-help-bounces@...] On Behalf
> Of Abel Braaksma
> Sent: 16 July 2008 09:09
> To: Mailing list for the SAXON XSLT and XQuery processor
> Subject: Re: [saxon] Stopping the evaluation of an XQuery in .NET
>
>
> Michael Kay wrote:
> > You can catch a StackOverflow exception in Java, but I'm not sure
> > whether you can do so on .NET.
> >
> >  
>
> Hi Michael,
>
> On .NET it is far from trivial to catch a
> StackOverflowException, because Microsoft discouraged it by
> making it hard in prior-to-.net-2.0 versions. From .Net 2.0
> onwards it is impossible, but you can create an application
> domain and let that crash instead of your whole application.
>
> From:
> http://msdn.microsoft.com/en-us/library/system.stackoverflowex
> ception.aspx
> In prior versions of the .NET Framework, your application
> could catch a StackOverflowException object (for example, to
> recover from unbounded recursion). However, that practice is
> currently discouraged because significant additional code is
> required to reliably catch a stack overflow exception and
> continue program execution.
>
> Starting with the .NET Framework version 2.0, a
> StackOverflowException object cannot be caught by a try-catch
> block and the corresponding process is terminated by default.
> Consequently, users are advised to write their code to detect
> and prevent a stack overflow. For example, if your
> application depends on recursion, use a counter or a state
> condition to terminate the recursive loop. Note that an
> application that hosts the common language runtime (CLR) can
> specify that the CLR unload the application domain where the
> stack overflow exception occurs and let the corresponding
> process continue.
>
> Cheers,
> -- Abel --
>
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK &
> win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Abel Braaksma (online)]

Michael Kay wrote:
> Thanks for this info.
>
> The other relevant point, of course, is that if your "infinite recursion"
> involves a tail-call, then you won't get a stack overflow exception anyway;
> instead you will get an infinite loop.
>  

I was under the impression that tail-call optimization was only
available on the paid SA edition of Saxon? And, though I may be wrong
here, the majority of your users are the open source / free version users?

> Perhaps I need to add an option to limit the recursive depth at the Saxon
> level. I can't say I'm enthusiastic about this: (a) it involves a run-time
> cost, and (b) 99.99% of users won't know how to set it correctly.
>  

If it helps: a "competitor" product, Altova XML, has an option to limit
the recursion depth. However, setting it only yields effect on low
values (it seems to have a build in limit that it cannot surpass, which
makes the "competitor" a bad candidate for deep recursion projects).

Maybe you can include it in a debug version of the project? That way one
would only use it while testing, using the debug version, enabling
maximum recursion depth. And in the release version all these checks are
removed.

Cheers,
-- Abel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Michael Kay]

> I was under the impression that tail-call optimization was
> only available on the paid SA edition of Saxon?

No, this particular optimization is available in both versions (I would
probably have made it SA-only, but it was done before the split).

> And, though I
> may be wrong here, the majority of your users are the open
> source / free version users?

I wish you were wrong! Fortunately the minority who buy the commercial
version is large enough to keep everyone happy.
>
> > Perhaps I need to add an option to limit the recursive depth at the
> > Saxon level.
>
> Maybe you can include it in a debug version of the project?

It doesn't actually need a separate version of the product, it just needs
(to do it efficiently) an option to compile the added logic conditionally
into the run-time code of the query/stylesheet when it is needed, probably
as an extra hidden parameter to each function or template.

Michael Kay
http://www.saxonica.com/


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Dimitre Novatchev]

> > The other relevant point, of course, is that if your "infinite recursion"
> > involves a tail-call, then you won't get a stack overflow exception anyway;
> > instead you will get an infinite loop.
> >
>
> I was under the impression that tail-call optimization was only
> available on the paid SA edition of Saxon? And, though I may be wrong
> here, the majority of your users are the open source / free version users?

Perhaps at this moment we should be reminded that different XSLT
processors handle tail recursion differently, and some (most) do not
handle it at all. To avoid the consequences of very deep recursion one
can always use the DVC (Divide and Conquer) technique, which is
independent of XSLT processor vendor.

A refresher: using DVC the maximum recursion depth is brought down
from N to log2(N). That means, for example, from one million to just
nineteen.

Of course, DVC is not always straightforward (I remember once I
intended to convert the LR-parser available in FXSL from left-to-right
to a DVC one :)  ).

However, if the problem can be solved with some kind of folding (using
a function such as f:foldl() or f:foldr(), or f:fold-tree()), and most
problem can!, then one can simply use the DVC implementation of
f:foldl(), available in FXSL. No additional effort involved!


--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play



On Wed, Jul 16, 2008 at 1:37 AM, Abel Braaksma <abel.online@...> wrote:

>
> Michael Kay wrote:
> > Thanks for this info.
> >
> > The other relevant point, of course, is that if your "infinite recursion"
> > involves a tail-call, then you won't get a stack overflow exception anyway;
> > instead you will get an infinite loop.
> >
>
> I was under the impression that tail-call optimization was only
> available on the paid SA edition of Saxon? And, though I may be wrong
> here, the majority of your users are the open source / free version users?
>
> > Perhaps I need to add an option to limit the recursive depth at the Saxon
> > level. I can't say I'm enthusiastic about this: (a) it involves a run-time
> > cost, and (b) 99.99% of users won't know how to set it correctly.
> >
>
> If it helps: a "competitor" product, Altova XML, has an option to limit
> the recursion depth. However, setting it only yields effect on low
> values (it seems to have a build in limit that it cannot surpass, which
> makes the "competitor" a bad candidate for deep recursion projects).
>
> Maybe you can include it in a debug version of the project? That way one
> would only use it while testing, using the debug version, enabling
> maximum recursion depth. And in the release version all these checks are
> removed.
>
> Cheers,
> -- Abel
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help