I think this is probably easy to fix -- my guess is an integer overflow. If someone wants to work on this and needs some help, let me know.

The updated configuration string is

./fast-downward.py $BENCHMARKS/airport/p50-airport5MUC-p15.pddl --search "eager_greedy([lmcount(lm_factory=lm_reasonable_orders_hps(lm_hm()))])"

When I run this with a memory limit, I quickly run out of memory with this (end of) output:

INFO     search command line string: /home/helmert/downward/master/builds/release/bin/downward --search 'eager_greedy([lmcount(lm_factory=lm_reasonable_orders_hps(lm_hm()))])' --internal-plan-file sas_plan < output.sas
[t=1.645e-05s, 9880 KB] reading input...
[t=0.0757357s, 22020 KB] done reading input!
[t=0.0771249s, 22416 KB] Initializing landmark count heuristic...
[t=0.0771588s, 22416 KB] Generating landmark graph...
[t=0.0784749s, 23528 KB] Building a landmark graph with reasonable orders.
[t=0.0797567s, 24448 KB] h^m landmarks m=2
Failed to allocate memory.
Memory limit has been reached.
Peak memory: 3695084 KB
Remove intermediate file output.sas
search exit code: 22

Driver aborting after search
INFO     Planner time: 2.8e+01s

This was previously accidentally posted as a summary rather than change note. Clemens already answered it in msg9756.

Can you include a logfile? On my computer this does not segfault, it just uses more and more memory (~16 GiB) until I have to kill it. Airport #50 is a giant task, so this would perhaps be a performance issue but not necessarily a bug. I wonder if the segfault is just a symptom of running out of resources or a genuine bug.

You can see the meaning of the exit codes here: https://github.com/aibasel/lab/blob/master/downward/outcomes.py

256 - 11 = 245
11 = signal.SIGSEV

According to driver.log on the grid, the planner exit code was 245. What does this mean? It's not listed on the page for exit codes on the Fast Downward website.

The driver.log file should give you the planner's exit code, which might be helpful.

Adding the requested log.

As of now, I'm somewhat unsure whether it really is a segfault. It was listed as such in the experiments I ran on the grid, but doesn't say so in the log.

(moving Clemen's report to the change notes)

A segfault is triggered during computation of the landmark graph (i.e., LandmarkFactory::compute_lm_graph(...)) for exactly one task in the entire benchmark set. The following configuration reproduces this error:

./fast-downward.py $BENCHMARKS/airport/p50-airport5MUC-p15.pddl --search "eager_greedy([lmcount(lm_factory=lm_hm(reasonable_orders=true))])"