Correctly parse libpython path from /proc/pid/maps for chrooted processes #562
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes: #553
See my analysis in #553 (comment). My understanding is that
/proc/pid/root
points to the root as the process sees it, while/proc/pid/maps
give us paths as WE see it. We (py-spy) are not chrooted when py-spy runs outside the chroot, so we need to strip the chroot from the/proc/pid/maps
value. As a generalization, we always strip the path, which in most cases is just/
if the process is not chrooted.I tested it with this application:
Try to profile this Python app with py-spy from master, and you'll get
Error: No such file or directory (os error 2)
as seen in the ticket. Try with this branch and it works fine :)Note that we need to fix only the path of libpython and not of python bin, because since #364 we access
/proc/pid/exe
directly without readlinking it, and it works whether chroot is in effect or not (I tested it as well, profiled a chrooted app that's not--enable-shared
and it works fine on master).I'm opening as draft because I still want to test a few more areas (for example, what if py-spy runs in the same chrooted container?) but overall this looks good :)