Segmentation Fault Error

[davidrjones77]

Hello, I love this extension and have been very excited to use it!
However today I have encountered the following error when running the default planner:

Starting search with IW (time budget is 60 secs)...
/app/plan: line 3: 8754 Segmentation fault timeout 10 "$(dirname "$0")"/siw-then-bfsf --domain $1 --problem $2 --output $3
Suspected timeout.

It seems to be caused by the presence of certain actions simultaneously in the domain.
I can supply more details if needed.

Thanks!

[jan-dolejsi]

Glad you see value in this work and are enjoying the ride.

The error report you pasted looks like the output of the solver at planning.domains. I am actually not sure which one it is nowadays. That is the default planner, but you can bring it your own.

We can help you diagnose PDDL model issues, if you can save them into a session at http://editor.planning.domains/ and include a link to the session (the read-only link) here, or at stackoverflow or the planning Slack channel.

[haz]

This was solved after a discussion over on the slack channel. It was an error in the problem's initial state (had negated fluents) which the online solver didn't like.

[Asriel31]

Is-it possible to install a solver available from vscode on Mac osx M1?

[haz]

The ARM processor? No, we don't have a solution for that yet.

[djiti]

It depends on how much you want your solver on Apple Silicon (ARM64). Here is a quick way to let Docker abstract away the emulation of AMD64 on ARM64, orchestrated by Dev Container / Docker Compose.

I have configured the bare minimal, i.e. only the planner.
Mind that I "force" the PDDL extension settings directly in devcontainer, so that it works "out of the box".

This setup happens to work on many platforms, including... GitHub Codespaces is you are so inclined, if you have a (free) GitHub account:

[Asriel31]

Thk’s very much for this answer Le sam. 5 oct. 2024 à 17:15, Guillaume Tamboise ***@***.***> a écrit :

…

It depends on how much you want your solver on Apple Silicon (ARM64). Here <https://github.com/djiti/vscode-pddl-devcontainer/tree/first> is a quick way to let Docker do the "hard work" of emulating AMD64 on ARM64, orchestrated by Dev Container / Docker Compose. I have configured the bare minimal, i.e. only the planner. Mind that I "force" the PDDL extension settings directly in devcontainer, so that it works "out of the box". This setup happens to work on many platforms, including... GitHub Codespaces is you are so inclined, if you have a (free) GitHub account: image.png (view on web) <https://github.com/user-attachments/assets/fad462bd-7b14-4e8d-92cb-8985d72d3374> image.png (view on web) <https://github.com/user-attachments/assets/697f0959-1be5-4437-b35e-17fd2bdd6705> image.png (view on web) <https://github.com/user-attachments/assets/7cb99e6e-8c76-4926-a049-18152b4b61a6> — Reply to this email directly, view it on GitHub <#115 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ2HOXHGF4VZSU4J243Y5L3ZZ767RAVCNFSM6AAAAABPF5Z37OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGA4DSMBZGI> . You are receiving this because you commented.Message ID: ***@***.***>

[haz]

Hold up...@djiti: is this a legit way to run all of the existing singularity-based planutils packages (compiled for amd64) on the arm M1 chips? Since when was this possible?

[djiti]

Docker using Rosetta for AMD64 emulation on Apple Silicon? I have always seen it, at least since April 2022. It used to be a lot more common to see this warning, before most Docker images got rebuilt for ARM64:

I am not familiar with Singularity (outside of reading for 10 minutes about it), but I could imagine potential problems around accessing the GPU, specialised HPC hardware (InfiniBand and such) if nothing has been done to support Apple Silicon, or if there are specific expectations on how things should look like inside the container (picked up from /proc, /sys or similar).
[I had a lot of "fun" playing with ePBF on Docker on Mac, anything that got close to kernel space required a bit of patience. What would typically bite me is compilers/headers not ready to deal with linuxkit:

root@244cd5539cd8:~# uname -a
Linux 244cd5539cd8 6.10.4-linuxkit #1 SMP Mon Aug 12 08:47:01 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

]

All I can say at this point is that all these packages install successfully - whenever they actually "work" beyond "hello world" is something else.

If I start picking other packages randomly, I can see some that do not install/build.
In my docker run -it --privileged aiplanning/planutils:latest bash, after planutils activate, if I planutils install ipc2023_odin then besides warnings such as

Warning: cannot find your CPU L2 cache size in /proc/cpuinfo

I end up with

[...]
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
--------------------------------------------------
Configuration summary for cudd 3.0.0

Build system   : x86_64-unknown-linux-gnu
Host system    : x86_64-unknown-linux-gnu
Prefix         : '/usr/local'
Compilers      : 'gcc    -m64 -g -O3 -w'
               : 'g++    -m64 -std=c++0x -g -O3 -DNDEBUG -fomit-frame-pointer'
Shared library : no
 dddmp enabled : no
 obj enabled   : yes
--------------------------------------------------
[  2%] Performing build step for 'libcudd'
make[4]: *** write jobserver: Bad file descriptor.  Stop.
make[4]: *** Waiting for unfinished jobs....
make[4]: *** write jobserver: Bad file descriptor.  Stop.
make[3]: *** [Makefile:1047: all] Error 2
make[2]: *** [search/CMakeFiles/libcudd.dir/build.make:86: search/libcudd-prefix/src/libcudd-stamp/libcudd-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:198: search/CMakeFiles/libcudd.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
Traceback (most recent call last):
  File "build.py", line 149, in <module>
    main()
  File "build.py", line 145, in main
    build(config_name, CONFIGS[config_name], make_parameters)
  File "build.py", line 122, in build
    try_run([MAKE] + make_parameters, cwd=build_path)
  File "build.py", line 98, in try_run
    subprocess.check_call(cmd, cwd=cwd)
  File "/usr/lib/pypy3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['make', '-j10']' returned non-zero exit status 2.
FATAL:   While performing build: while running engine: exit status 1
Finished installing ipc2023_odin (size: 20K)
(planutils) root@8b70c84164f4:~$ 

Is there a test suite somewhere I could run to see how well this planutils image actually works on emulated AMD64?

[haz]

Sorry this slipped by! Missed it in the sea of GitHub notifications I've had as of late. The planners you list are a good representative set. In particular, you could test things with lama-first and dual-bfws-ffparser and these two files:

• https://www.haz.ca/planning-domains/classical/sokoban-sat11-strips/domain.pddl
• https://www.haz.ca/planning-domains/classical/sokoban-sat11-strips/p03.pddl

So after planutils activate, something like...

wget https://www.haz.ca/planning-domains/classical/sokoban-sat11-strips/domain.pddl
wget https://www.haz.ca/planning-domains/classical/sokoban-sat11-strips/p03.pddl
lama-first domain.pddl p03.pddl

[djiti]

It "works in my container", for both lama-first and dual-bfws-ffparser. I have updated the repo to add dual-bfws-ffparser.

Full output attached:

• out.json
• out-dual.json

[haz]

Extremely promising, thank you! Going to try and find an ARM chip dev machine to fully kick the tires on this, and hopefully put this long-standing issue behind us.