Issue984

Title Segfault in h^m Landmark Factory
Priority bug Status chatting
Superseder Nosy List clemens, jendrik, malte, silvan
Assigned To Keywords
Optional summary

Created on 2020-11-20.14:31:06 by clemens, last changed by malte.

Files
File name Uploaded Type Edit Remove
driver.log clemens, 2020-11-20.19:29:32 text/x-log
run.log clemens, 2020-11-20.19:12:44 text/x-log
Messages
msg10800 (view) Author: malte Date: 2022-07-19.21:06:47
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.
msg10739 (view) Author: malte Date: 2022-07-06.16:42:46
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
msg10738 (view) Author: malte Date: 2022-07-06.16:39:44
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.
msg9759 (view) Author: jendrik Date: 2020-11-20.19:42:55
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
msg9758 (view) Author: clemens Date: 2020-11-20.19:29:32
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.
msg9757 (view) Author: jendrik Date: 2020-11-20.19:19:36
The driver.log file should give you the planner's exit code, which might be helpful.
msg9756 (view) Author: clemens Date: 2020-11-20.19:12:44
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.
msg9755 (view) Author: silvan Date: 2020-11-20.15:19:21
(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))])"
History
Date User Action Args
2022-07-19 21:06:47maltesetmessages: + msg10800
2022-07-06 16:42:46maltesetmessages: + msg10739
2022-07-06 16:39:44maltesetmessages: + msg10738
summary: 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. ->
2020-11-20 19:42:55jendriksetmessages: + msg9759
2020-11-20 19:29:32clemenssetfiles: + driver.log
messages: + msg9758
2020-11-20 19:19:36jendriksetmessages: + msg9757
2020-11-20 19:12:44clemenssetfiles: + run.log
messages: + msg9756
2020-11-20 18:48:53maltesetsummary: 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.
2020-11-20 15:20:40silvansetnosy: + jendrik
2020-11-20 15:19:22silvansetstatus: unread -> chatting
nosy: + malte, silvan, clemens
messages: + msg9755
summary: 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))])" -> (no value)
2020-11-20 14:31:06clemenscreate