Exit status of search

[Robert P. Goldman]

Is there some way to distinguish, from the exit status of fast
downward's search, whether the search has encountered an error, or
exhaustively explored the search space? It looks like an exit status
of 1 means exhaustive search and failure. Is there a different value
sent when a real error is encountered?

thanks!

[Malte Helmert]

There is no good way at the moment. We tend to parse the output to
distinguish these cases (stdout and stderr). The planner is usally
silent on stderr, so any output there is an indication that something
went wrong (such as running out of memory).

Cheers,

Malte

[Robert Goldman]

Would it be a reasonable extension to reserve exit status 1 for "no plan" and catch other errors and set exit status 2 (or possibly vice versa, if other bits are likely to cause exit status to flow through)?

I ask because I am not sure how to revise my shell script to distinguish these cases. I  suppose I can check for an empty standard error, but as a wrapper that seems more brittle than catching an exit code....

[Malte Helmert]

On 30.05.2012 17:38, Robert Goldman wrote:
> Would it be a reasonable extension to reserve exit status 1 for "no
> plan" and catch other errors and set exit status 2 (or possibly vice
> versa, if other bits are likely to cause exit status to flow through)?
>
> I ask because I am not sure how to revise my shell script to distinguish
> these cases. I suppose I can check for an empty standard error, but as
> a wrapper that seems more brittle than catching an exit code....

Our current convention, which I don't think we follow strictly yet, is 2
for usage error (i.e., bad command-line syntax) and 1 for all other
kinds of errors including "no plan found". I'm not sure if "no plan
found", in a case where the algorithm proves that no plan exists, should
give a non-zero exit code at all. In any case it should definitely be
distinguished from actual errors in terms of exit code. My preferred
suggestion, if this should give a nonzero exit code at all, would be:

1 - no plan found
2 - usage error
3 - everything else (maybe distinguish these further)

Maybe we should also distinguish "no plan found and we proved that none
exists" from "no plan found, but the used algorithm was incomplete". Not
sure. (Certainly we don't currently have the necessary introspection
features to find out which of the two cases applies.)

But independently of this, what happens on out-of-memory conditions is
currently up the OS. The planner doesn't currently catch failed memory
allocation at all, so there is no explicit setting of an exit code that
we could change. So whatever outside behaviour you see is not
(currently) under the control of our code.

It would be a good idea to change this, of course, along with unifying
the exit codes. Unfortunately it's one of a thousand things that we
ought to do, so not sure if we can get to it any time soon (or at all).
:-( But if you want to move this forward, the first step would be to
open an issue in the tracker (of type "wish").

Cheers,

Malte

[Robert P. Goldman]

On May 30, 11:13 am, Malte Helmert <malte.helm...@unibas.ch> wrote:
> On 30.05.2012 17:38, Robert Goldman wrote:
>
> > Would it be a reasonable extension to reserve exit status 1 for "no
> > plan" and catch other errors and set exit status 2 (or possibly vice
> > versa, if other bits are likely to cause exit status to flow through)?

> if you want to move this forward, the first step would be to
> open an issue in the tracker (of type "wish").

Done: http://issues.fast-downward.org/issue338

Thanks for the explanation: it made revising my script much easier
than trying to guess!

Best,
R

[Malte Helmert]

On 30.05.2012 19:35, Robert P. Goldman wrote:
> On May 30, 11:13 am, Malte Helmert <malte.helm...@unibas.ch> wrote:
>> On 30.05.2012 17:38, Robert Goldman wrote:
>>
>>> Would it be a reasonable extension to reserve exit status 1 for "no
>>> plan" and catch other errors and set exit status 2 (or possibly vice
>>> versa, if other bits are likely to cause exit status to flow through)?
>
>> if you want to move this forward, the first step would be to
>> open an issue in the tracker (of type "wish").
>
> Done: http://issues.fast-downward.org/issue338

Perfect, thanks!

[Erez Karpas]

Another option to check whether the planner found a plan or not is to check the plan output file.

I think the file is not created unless a plan is found, although this would not distinguish between an error and a "no solution found".

Cheers,

Erez.

--

--------------------------------------------------------------
"Adventure is just bad planning."
    Roald Amundsen
    Norwegian Arctic & Antarctic explorer  
    (1872 - 1928)                                     
--------------------------------------------------------------

[Robert Goldman]

Yes.  I am using fast downward in a verification-like application, so it's critical to be able to distinguish between "exhaustive search, no solution found" (the property in question is satisfied) and "error" (out of memory, or other exception condition: no conclusion can be drawn about the property).

Plan versus no-plan is quite adequately handled.  It's the other distinction that's problematic.

Cheers,

r