-
Notifications
You must be signed in to change notification settings - Fork 439
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
get_process_exe on windows is_python_bin check #40
Comments
Thanks for the detailed bug report! This shouldn't be all that hard to handle, it's just not something that I've tested (the earliest version of windows I've tested with is windows7, and I'm not sure if this problem will also exist there). I think the best solution here is to fall back to matching the filename (python.exe or similar) if we can't find an exact match on the process exe. The exact match should work most of the time, and it lets us support embedded python enviroments like uwsgi etc. We can't just skip matching against the virtual memory maps because we need the memory offset that it's mapped into to handle ASLR (which probably doesn't apply to windows 2008, but still is important in general ). The CI script for windows is here: https://github.com/benfred/py-spy/blob/master/appveyor.yml - this does more than you strictly need to just build, installing rust and then going 'cargo build --release' should be enough to get building. I will probably have a fix for this tomorrow - |
If we failed to find the executable in the virtual memory maps, just take the first file we find. Sometimes on windows get_process_exe returns stale info =( #40 and on all operating systems I've tried, the exe is the first region in the maps
I didn't manage to reproduce this, but I believe the last commit there will fix this issue. |
fix is in 0.1.8 |
Thanks very much. 0.1.8 helps. Given the example above, got the fallback message in log. But then it seems trying to open the old path (c:\foo\bar\python26\python.exe) and failed. Copied c:\foo\bar.moved\python26 back to old c:\foo\bar\python26, and ran py-spy again. Then it works!
I will look more later. And maybe just copy python.exe works rather than the full python dir. Btw, tried to build Rust nightly, Python 2.6/2.7, VC for python 2.7 on windows 10 vm. It was mostly not hard and smooth, but got stuck on proc-macro2, which seems to be an rust/dll issue something to do with msvcr90.dll. Have not made it work yet. Maybe need visual studio 2015 which is quite heavy.
|
Hi,
I am still wondering how to deal with "Couldn't find binary in virtual memory maps". In this case the python executable is moved or renamed on Windows. This happens to me with the latest 0.1.6 after #34.
It looks like Windows somehow caches the old path such as "c:\foo\bar\Python26\python.exe" on Windows 2008 R2. (I know, python26 and Windows 2008 is old, but may be unrelated to the issue here I think.)
It was moved to c:\foo\bar.moved. Then the target process started. Ran py-spy on the target pid.
It seems that utils::get_process_exe and QueryFullProcessImageNameW return the old path "c:\foo\bar" not "c:\foo\bar.moved"
I searched and ran various utilities to find c:\boo\bar and why. Try clear some memory caches and restarted some windows services etc, nothing works. Logout doesn't help.
Only need to restart the machine. Then it found c:\boo\bar.renamed, and worked.
To work aroud, I can change not to move/rename the deployment. But because the "freezing" process is rare, hard to reproduce.
It's difficult to miss the py-spy opportunity and change the process, restart, and reproduce. I also don't have the pdb for the old python26 distribution in order to get the stack trace. So really need to get help by using py-spy.
Also try build a patch and bypass "is_python_bin" check. But it needs Rust on Windows. Have not found scripts eg. for travis, and found no quick Docker images. Is there instruction for building on Windows?
Also wonder if py-spy can analyze a full or mini dump on Windows or core dump on Linux/Mac, rather than monitoring on a live process. Like to this in a separate issue.
Thanks in advance for your help and advice. py-spy is awesome!
Here were the steps:
c:\foo\bar\Python26 was installed.
It was moved to c:\foo\bar.moved\Python26
Then started the target
In another admin window cmd:
py-spy logs:
The text was updated successfully, but these errors were encountered: