Segmentation fault running parser to check plan

[rpgoldman]

Method matchings failed, and then there's a seg fault. Here's an example run and output:

$ pandaPIparser -v domain.hddl p01.hddl ipyhopper-plans/p01.txt
pandaPIparser is configured as follows
  Colors in output: true
  Mode: plan verification
  Verbosity: 0
  Lenient mode: false
  Ignore given order: false

Checking the given plan ...
Task id=0 has itself as a subtask.
IDs of subtasks used in the plan exist: false
Tasks declared in plan actually exist and can be instantiated as given: true
Methods don't contain duplicate subtasks: true
Methods don't contain orphaned tasks: true
Root tasks have no matchings for the initial plan.
Task with id=1 has no matchings for its subtasks.
Task with id=2 has no matchings for its subtasks.
Task with id=3 has no matchings for its subtasks.
Task with id=4 has no matchings for its subtasks.
Task with id=5 has no matchings for its subtasks.
Task with id=6 has no matchings for its subtasks.
Task with id=7 has no matchings for its subtasks.
Task with id=13 has no matchings for its subtasks.
Task with id=14 has no matchings for its subtasks.
Task with id=15 has no matchings for its subtasks.
Task with id=16 has no matchings for its subtasks.
Task with id=17 has no matchings for its subtasks.
Task with id=18 has no matchings for its subtasks.
Task with id=21 has no matchings for its subtasks.
Task with id=22 has no matchings for its subtasks.
Task with id=23 has no matchings for its subtasks.
Task with id=24 has no matchings for its subtasks.
Task with id=25 has no matchings for its subtasks.
Task with id=26 has no matchings for its subtasks.
Methods can be instantiated: false
Segmentation fault: 11

The segmentation fault occurs with all three of the verbosity settings, -v, -V, and -W.

As usual, I have posted the three input files as a gist.

Looking at the most verbose output, I see some oddities like this:

Checking the given plan ...
Task id=0 has itself as a subtask.
IDs of subtasks used in the plan exist: false

This is quite odd since all the task IDs are greater than zero in this plan. Reading further, it looks like perhaps task zero is the _top pseudo-task?

According to this, the methods cannot be instantiated and the parser reports there are no matchings for any of its tasks. Here's an example:

Generating Matchings for task with id=23
 Matching Task 25 Curpos=0 #sources=1
 Task is: turn-on-instrument satellite0 instrument0
 Attempting matching with source __t_id_6
  Setting ?s = satellite0
  Setting ?i = instrument0
   Matching Task 26 Curpos=1 #sources=1
   Task is: calibrate-instrument satellite0 instrument0
   Attempting matching with source __t_id_7
    Setting ?s = satellite0
    Setting ?i = instrument0
     Matching Task 0 Curpos=2 #sources=0
     Task is: __top

This corresponds to

23 prepare-instrument satellite0 instrument0 -> prepare 25 26 

whose definition is:

  (:method prepare
          :parameters (?i - instrument ?s - satellite)
          :task (prepare-instrument ?s ?i)
           :ordered-subtasks
           (and (turn-on-instrument ?s ?i)
                (calibrate-instrument ?s ?i)))

25 and 26 are:

25 turn-on-instrument satellite0 instrument0 -> already-on 
26 calibrate-instrument satellite0 instrument0 -> no-calibration-needed 

defined as:

  (:method already-on
    :parameters (?i - instrument ?s - satellite)
    :task (turn-on-instrument ?s ?i)
    :precondition
    (power_on ?i)
    :ordered-subtasks
    ())

and

  (:method no-calibration-needed
    :parameters (?i - instrument ?s - satellite)
    :task (calibrate-instrument ?s ?i)
    :precondition
    (and (power_on ?i)
         (calibrated ?i))
    :ordered-subtasks ())

Those both look ok to me, although I could be missing something.

[rpgoldman]

A SHOP plan, which looks very similar -- I think it's semantically identical -- checks successfully.

Is there any chance that pandaPIparser has some expectation about the index values? I note that the index values in the successfully-checked (SHOP) plan are sequential across the plan sequence, and that all the complex tasks in the decomposition part have IDs that are greater than any idea in the plan sequence. Could this cause the difference in results?

Thank you!

[rpgoldman]

I have verified that it's numbering that is the problem. I wrote a (very ugly) perl script to renumber the plan that causes the seg fault and now it validates successfully.

Here is the renumbered plan file for comparison, which demonstrates that numbering is the source of the bug. I fear there's some place where the parser isn't checking array bounds or something, and that's why there's a seg fault.

p01-renumbered.txt

[galvusdamor]

This is strange. The problem is that I cannot reproduce the error with your first file (in the gist). For me the verifier validates the plans on all three levels of verbosity correctly.

Also: the verifier does not make any assumptions on the numbering - and the numbering should (barring any bug) be completely irrelevant. Some of the planners regularly produce very strange numberings (e.g. starting the primitive plan with ID 50000 or the like) and this has never caused any problem.

I assume that this is caused by the same problem as issue #23.

It seems that for some strange reason in your case, the planner parses something in the file as

Task id=0 has itself as a subtask.

One option might be the extra empty line that both the file p01.txt here and the plan in #23 have. I mean the line before the root line.

The only cause that I can think of is a strange interaction between / implementation of cin and getline that is different under MacOS than under linux. The relevant code lines are in the file src/plan.cpp in lines starting from 137. What I do here is in line 160 search for the next token and then read the rest of that line. This should just read over the empty line, but maybe MacOS behaves differently here?
I would think that the empty line is somehow read as something that contains two zeros or something like that - which would be very strange.

[galvusdamor]

For -V and -W, the verifier outputs in the beginning what he thinks he is reading from the input. Can you verify that this looks as in the plan file on your machine?