Created attachment 127224 [details] Possible fix by falling back to alternate PR_SET_PTRACER call SUMMARY When running Ubuntu 18.04 on Windows-Subsystem-for-Linux (WSL), I have noticed the following error during every run of Valgrind: error calling PR_SET_PTRACER, vgdb might block STEPS TO REPRODUCE 1. Use Ubuntu 18.04 on WSL 2. Build Valgrind from git ./autogen.sh && ./configure && make -j8 --quiet check 3. Run valgrind against any program: VALGRIND_LIB=./.in_place VALGRIND_LIB_INNER=./.in_place/ ./coregrind/valgrind pwd OBSERVED RESULT error calling PR_SET_PTRACER, vgdb might block EXPECTED RESULT no error SOFTWARE/OS VERSIONS Windows: 10 (1909) 10.0.18363.720 Linux: Ubuntu 18.04 on WSL Valgrind: 3.16.0.GIT ADDITIONAL INFORMATION This is caused by a bug in noted in the following stack overflow: https://stackoverflow.com/questions/57206233/valgrind-showing-error-calling-pr-set-ptracer-vgdb-might-block It was logged with Microsoft as: https://github.com/microsoft/WSL/issues/3053 It has apparently been fixed in WSL build 17723: https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-17723-fast However it seems that it has not yet reached Windows Update (despite my PC being at build 18363) The error comes from VG_(set_ptracer)() in coregrind/m_gdbserver/remote-utils.c It appears that the following call fails: ret = VG_(prctl) (PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0); But if the following alternate line is enabled, the call succeeds: ret = VG_(prctl) (PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0); I believe we could work around this by just failing-over from the first prctl to the second. I will submit a patch which does that.
Thanks for the proposed patch. I do not remember the reason for the line ret = VG_(prctl) (PR_SET_PTRACER, 1, 0, 0, 0); prctl PR_SET_PTRACER documentation indicates that the second argument is either PR_SET_PTRACER_ANY (to allow any process to ptrace the caller), or a pid (to allow pid to ptrace the caller) or 0 (to not allow anymore a process to ptrace the caller). So, the reason of the call with the pid 1 is not clear (anymore to me. I must have had a good reason at a time, but not commented :(. That being said: Does calling set_ptracer with value 1 effectively allow vgdb to get a blocked valgrind process out of the syscall ? In other words, before your patch: valgrind sleep 100 in another window: vgdb help and vgdb should block or give error msg or similar (you might use vgdb -d -d -d -d help to get more info about what is going on) and after your patch, vgdb -d -d -d -d help should be able to wake up valgrind and produce the help text.
Thanks for the pointers on testing it on vgdb. It looks like it still hangs vgdb :-( I too am not sure what the prctl(PR_SET_PTRACER, 1, 0, 0, 0) call is trying to achieve. It seems to succeed but still leaves vgdb blocked.
(In reply to Evan Hunter from comment #2) > Thanks for the pointers on testing it on vgdb. > It looks like it still hangs vgdb :-( > I too am not sure what the prctl(PR_SET_PTRACER, 1, 0, 0, 0) call is trying > to achieve. It seems to succeed but still leaves vgdb blocked. Using the debug options -d -d -d of vgdb and -v -v -v -d -d -d of valgrind, it should be possible to have an idea about what does not work.
*** Bug 443426 has been marked as a duplicate of this bug. ***
I don't see any problem with WSL2 on Windows 11, openSUSE-Leap-15.6