-
|
Hi all, I'm trying to profile my python code on an ARMv7 system. I seem to hit different problems getting memray to run depending on how I build/run it. The closest I have gotten is to docker buildx bake build for the python docker image that I use and then run from there. Docker bake memray-build This sucessfully builds the memray.whl file for the architecture. And it seems to run on a Hello world python file. However, when I run against the actual codebase, I get a memory error. Running the exact same image but with "python -m pyaware /etc/aware" instead of "python -m memray run -m pyaware /etc/aware" Does anyone have any insight on how to get this working? |
Beta Was this translation helpful? Give feedback.
Answered by
godlygeek
May 12, 2024
Replies: 1 comment 5 replies
-
|
I don't think Memray has ever been tested on aarch32 or ARMv7. I'd suggest trying to run Memray's test suite, and see whether it passes. That will tell us whether this is a problem of Memray not working properly on that architecture, or of Memray not playing nicely with the package you're testing it with. From a clone of the repo, the test dependencies can be installed with |
Beta Was this translation helpful? Give feedback.
5 replies
-
|
I guess I have my answer. Its untested/unsupported. Using a new docker buildx build I've managed to run the tests and have some failures. 1 is the sigint Thank you very much. Will report back if I get it working on my codebase, also for anyone else wanting to run it unsupported. DetailsDockerfile |
Beta Was this translation helpful? Give feedback.
-
|
Hm... It seems more likely to me that Does If the first succeeds and the second fails, that would definitely suggest a bug of some sort in Memray... |
Beta Was this translation helpful? Give feedback.
-
|
Yes it worked on mp.Lock() for no memray but failed on memray run Details |
Beta Was this translation helpful? Give feedback.
-
|
Hm, ok. So... something about running under Memray is definitely breaking
OK, a few things to try. See if setting these two environment variables before building Memray changes anything: I'm guessing it won't, but it'd be nice if it did 😅. On the off chance that it does change the behavior, try each of those environment variables one at a time, and report which one fixes the issue. Otherwise, if things are still failing, I'd love it if you could share strace logs of both of those processes: RUN apt-get -y install strace
RUN strace -o no_memray.out -s 1024 -f python3 -c "import multiprocessing as mp; mp.Lock()"
RUN strace -o with_memray.out -s 1024 -f python3 -m memray run -c "import multiprocessing as mp; mp.Lock()" || trueand then https://gist.github.com/ the two |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I still intend to get to this. Just been very busy. I'm also pazzarpj |
Beta Was this translation helpful? Give feedback.
Answer selected by
pazzarpj
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't think Memray has ever been tested on aarch32 or ARMv7. I'd suggest trying to run Memray's test suite, and see whether it passes. That will tell us whether this is a problem of Memray not working properly on that architecture, or of Memray not playing nicely with the package you're testing it with. From a clone of the repo, the test dependencies can be installed with
pip3 install -r requirements-test.txt, and from there apython3 -m pytest tests/will run the test suite.