https://bugs.kde.org/show_bug.cgi?id=396415
Geoffrey Thomas <geo...@ldpreload.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |CONFIRMED
Ever confirmed|0 |1
CC| |geo...@ldpreload.com
--- Comment #4 from Geoffrey Thomas <geo...@ldpreload.com> ---
I ran into this today myself and took a look at the code. The root cause is
simple - valgrind virtualizes lookups of "/proc/self/exe" and repoints them at
"/proc/self/fd/%d" for the open file handle of the program being instrumented.
But, for a script, this file handle points to the script itself, not to the
binary interpreting the script. Because the glibc dynamic linker uses
readlink("/proc/self/exe") (or actually readlinkat) to figure out where to
calculate $ORIGIN, this gets you the wrong result if your script and
interpreter are not in the same directory.
I think the fix is also conceptually simple. We already know the path to the
interpreter. It's the interp_name field in the ExeInfo, because valgrind had to
go look up the binary already to start running the script. We just need to open
that file and keep a file descriptor around. (I suspect it's safe to change the
existing cl_exec_fd to point to the interpreter instead of the script - the
only uses I see of it are things analogous to reading /proc/self/exe.) This is
probably easier for someone familiar with the code, but I'm happy to try my
hand at a patch if it's helpful.
--
You are receiving this mail because:
You are watching all bug changes.
