-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't run ACAS Xu example #735
Comments
Hmm so it looks like this is a problem on the Marabou end. But Vehicle's diagnosis is wrong, Marabou isn't running out of memory. Error code 4 is "illegal instruction". So there's something buggy in your build of Can you run vehicle compile
--target MarabouQueries
--specification acasXu.vcl
--network acasXu:acasXu_1_7.onnx
--property property3
--output queries and then run Marabou
acasXu_1_7.onnx
queries/property3-query1.txt and report the output? (I haven't tested that command myself. The first one compiles the queries, and the second one runs Marabou explicitly to capture it's full output). |
I've also transferred this issue to the main |
It outputs this:
I will try reinstalling marabou in case it changes anything |
Try compiling Marabou from source. This error implies that the binaries that you are using were compiled for a newer CPU. Would you be able to post the contents of |
I did compile Marabou from source, as per these instructions https://neuralnetworkverification.github.io/Marabou/Setup/0_Installation.html
|
It appears that the binaries distributed via PyPI require AVX-512, which your CPU does not support. (The full list of CPU extensions that are required but unsupported is AVX512, MODE64, BWI, NOVLX, VLX, and DQI, but I'm no expert, so some of these could be due to aliasing.) As you're compiling from source, I'm unsure if the same is true for the binaries you've built. You can verify the CPU extensions required by the binary you've built by running elfx86exts. Either way, this appears to be an issue with the way in which Marabou is built. I can submit an upstream issue, if you can provide me with some information:
|
Follow up:
So we can pretty confidently say the problem is due to the lack of AVC-512 support. |
2: It doesn't result in the same error I think, but here is the full output: Step_2_Output.txt 3:
|
That's a succesful run... That's... confusing. AND the executable you're running uses AVX-512 instructions... which your processor doesn't seem to support? |
I got the same 'out-of-memory' error when running the example on the Linux machine in the office, which has all the libraries installed and up to date. However, Ben can run the example on his laptop, which has a different version of Marabou - "origin/negative-dimensions-fix 8d26b936" retrieved on June 19th 2023. We haven't been able to find that version on the Marabou repository |
Do you think that's a genuine out of memory error this time? |
No, because it has 29gb available and exits after <1s as before |
And in both cases you've built Marabou from source? |
After reinstalling everything I have solved the problem - although the output:
is different to the tutorial example:
I'm working on recreating the issue so I can find the exact cause |
I wouldn't worry about too much. I really doubt that Marabou (and all the downstream tools it uses) make much effort in to ensuring stability of counter-examples across different platforms. As long as the overall answer is the same, i.e. |
When running these commands:
vehicle verify
--specification acasXu.vcl
--verifier Marabou
--network acasXu:acasXu_1_7.onnx
--property property3
I get this error:
When running compile and verify separately, compile works but verify gives same error. The files passed are attached, although they should be identical to the originals.
acasXu.zip
Module versions:
maraboupy==1.0.0
,vehicle-lang==0.11.0
OS is Ubuntu 22.04.3 LTS (jammy) running in WSL 2 on Windows 10 Pro, and I have 16gb of RAM available. I have set WSL to use all 16gb in its config (
grep MemTotal /proc/meminfo
returns 16gb) and tried WSL 1.According to
time
the command runs for 0.186s and there is no visible increase in memory on task manager - compared to 44s and a significant increase when running the mnist-robustness example (which runs fine).The text was updated successfully, but these errors were encountered: