search

jan-dolejsi / vscode-pddl

Planning Domain Description Language (PDDL) grammar, syntax highlighting, code snippets, parser and planner integration for Visual Studio Code.
MIT License
87 stars 22 forks source link

Segmentation Fault Error #115

Open davidrjones77 opened 2 years ago

davidrjones77 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 month ago

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

haz commented 1 month ago

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

djiti commented 1 month ago

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:

image image image
Asriel31 commented 1 month ago

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 https://github.com/jan-dolejsi/vscode-pddl/issues/115#issuecomment-2395089092, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ2HOXHGF4VZSU4J243Y5L3ZZ767RAVCNFSM6AAAAABPF5Z37OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGA4DSMBZGI . You are receiving this because you commented.Message ID: @.***>

haz commented 1 month ago

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 commented 1 month ago

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:

image

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 commented 3 weeks ago

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:

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 commented 3 weeks ago

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

image image

Full output attached:

haz commented 3 weeks ago

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.