--10797-- WARNING: unhandled syscall: 272 --10797-- You may be able to write your own handler. --10797-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --10797-- Nevertheless we consider this a bug. Please report --10797-- it at http://valgrind.org/support/bug_reports.html. fatal: unshare: Function not implemented
Platform: amd64. For more information about the unshare() system call, see also http://lwn.net/Articles/135321/.
Michael, can you supply a simple test case program?
The unshare system call should be simple enough to implement in itself - it only has a single argument which is a bitmask of flags. I just wonder what the interaction with other things may be though, as it effectively allows a thread to partially separate itself from it's parent so that they no longer share certain resources. We currently police what sets of flags we are prepared to allow to clone() and this call allows that to be changed later.
*** Bug 324486 has been marked as a duplicate of this bug. ***
I believe this bug is fixed in 3.11.0 (or before): # /home/amb/valgrind/install/bin/valgrind --version valgrind-3.11.0.SVN # /home/amb/valgrind/install/bin/valgrind unshare -n /bin/true ==60198== Memcheck, a memory error detector ==60198== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==60198== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info ==60198== Command: unshare -n /bin/true ==60198== whereas: # valgrind --version valgrind-3.10.0.SVN # valgrind unshare -n /bin/true ==60187== Memcheck, a memory error detector ==60187== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==60187== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==60187== Command: unshare -n /bin/true ==60187== --60187-- WARNING: unhandled syscall: 272 --60187-- You may be able to write your own handler. --60187-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --60187-- Nevertheless we consider this a bug. Please report --60187-- it at http://valgrind.org/support/bug_reports.html. unshare: unshare failed: Function not implemented ==60187== ==60187== HEAP SUMMARY: ==60187== in use at exit: 0 bytes in 0 blocks ==60187== total heap usage: 245 allocs, 245 frees, 22,384 bytes allocated ==60187== ==60187== All heap blocks were freed -- no leaks are possible ==60187== ==60187== For counts of detected and suppressed errors, rerun with: -v ==60187== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Yes Julian appears to have committed it in r14494. There's no validation of the argument so I suspect there may be ways to severely confuse valgrind but I guess we can deal with those as and when somebody finds them.