Comments (17)
The version tags actually do exist, but for some historical reason I have no context on we prepend a v
so the tags are v0.9.19
and v0.9.21
; I can work on getting rid of the prepending but you can see the tags here:
https://github.com/facebook/pyre-check/tags
The wheels can be reliably built in theory, although we might have some trouble actually accessing them (they are built by some internal CI processes that want to push the results to pypi); there's room for improvement here but it's what we have for now.
from pyre-check.
@vthemelis Yes that seems to be the case. When changing the image version to ubi9-9.4 everything seems to work properly
Should I close the issue?
from pyre-check.
I think that it would still be worth thinking about statically linking libc into the executable as part of the issue.
from pyre-check.
Hi @frederiksteiner thanks for the bug report!
Unfortunately there's not enough in the logs for me to have a very good guess the problem. A couple questions for you:
- What operating system are you on?
- Does running
pyre --sequential check
help any? If so, it's likely a failure in our parallelization logic.
One possibility is that we made some changes around scheduling workers (Pyre runs in parallel by default) that might be playing a role here; if we see that --sequential
is okay then this is an especially likely root cause.
from pyre-check.
- What operating system are you on?
I am running WSL2 with Ubuntu 20.04.5. Same error happens, when running pyre in a docker container (redhat/ubi8-minimal:8.9)- Does running
pyre --sequential check
help any? If so, it's likely a failure in our parallelization logic.
Nope, unfortunately, the error is the same
from pyre-check.
I'm having the same issue. I cannot replicate reliably in some environments but never get it on others.
0.9.19
works but 0.9.21
doesn't. --sequential
doesn't work.
@stroxler, could you provide the tags for versions 0.9.19
onwards? I don't see them on GitHub. Also, can you reliably rebuild the wheel for these versions?
from pyre-check.
@frederiksteiner I cannot repro with your repo and steps on Mac. Do you have a dockerfile that can reproduce the issue?
from pyre-check.
@vthemelis I added a Dockerfile to the github repo: https://github.com/frederiksteiner/pyre-bug/blob/master/Dockerfile
It's not the most beautiful dockerfile, but it should do the job I guess :)
from pyre-check.
Looks like the issue is that pyre requires glibc>=2.34
(?).
# /root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin
/root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin)
/root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin: /lib64/libc.so.6: version `GLIBC_2.29' not found (required by /root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin)
/root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin)
/root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin)
/root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /root/.cache/pypoetry/virtualenvs/bug-pyre-il7asoJj-py3.11/bin/pyre.bin)
from pyre-check.
@frederiksteiner, I guess that using a newer version of your operating system or upgrading glibc will resolve this for you. Also, I don't think that this is related to poetry.
@stroxler, would it be possible to statically link libc
in pyre?
from pyre-check.
Let's leave it open for now, I probably can't get an answer on statically linking this week but I'll ask around; that would probably be a great idea assuming there isn't something preventing it.
Also @vthemelis how did you get those logs? @samwgoldman had a theory that maybe OCaml is buffering stderr and then dying before it flushes, so I was wondering if we should look into it but I'm curious what worked for you.
from pyre-check.
@stroxler I got the logs by running pyre.bin directly (no arguments needed). The logs were in stderr and I opened #863 to propagate them through the python wrapper script.
from pyre-check.
I would look into the static linking bit but I don't have a Linux workstation handy which makes this a bit more tedious.
from pyre-check.
I had a quick look and in the end, I think that it may be a bad idea to statically link libc as this may make pyre even less compatible.
Looks like the best way is to use a manylinux container to build the wheel. I wonder if pyre could be build with such a container that supports an older version of libc.
from pyre-check.
Yeah, I think we came to the same conclusion.
Our current setup uses internal CI infra (which does not use or allow Docker) to build Pyre so we'll need to translate all of that into a setup we can containerize.
from pyre-check.
Should I wait until #863 is done or should I close the issue now?
from pyre-check.
We can close this, I'll keep working with @vthemelis to get #863 merged but I don't think that blocks this.
And I'll actually file a new issue for the glibc build since it's relatively clear what we need to do (and it may take some time)
from pyre-check.
Related Issues (20)
- How to support env['PYTHONPATH'] HOT 1
- How to use OS.enviorn as a taint source HOT 2
- Incremental check hangs on OS X HOT 4
- [pysa][MLH] Add a show to Registry
- [pysa][MLH] Hide warnings about high number of overrides
- [pysa][MLH] Hide model verification error for "X is not part of the environment"
- Build Pyre binaries using older Linux versions HOT 1
- The type check of numpy.lib.tests.test_format.$toplevel is taking more than ... (hangs indefinitely)
- Exec format error 'pyre-check/stubs/integration_test/.overridden'
- JSON schema for config file
- Pysa unable to use models with special characters / reserved keywords
- Installation of pyre not working due to unused requirement HOT 2
- Pyre does not reason about `if` statements with logical operators HOT 1
- Pyre installation procedure results in a mac os Mach binary installed in a Debian x86_i64 system HOT 1
- Pyre installation from source fails when building. HOT 5
- Pyre cannot narrow literal types
- Pysa does not complete the analysis of a tutorial example HOT 2
- Pyre exited with non-zero return code: 1 HOT 6
- Setting log level to CRITICAL still causes non critical message to be logged.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pyre-check.