Issue984

Title Segfault in h^m Landmark Factory
Priority bug Status chatting
Superseder Nosy List clemens, jendrik, malte, silvan
Assigned To Keywords
Optional 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.

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

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.
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
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
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