<<<test_start>>> tag=sched_getattr02_valgrind_memory_leak_check stime=1474195095 cmdline=" valgrind -q --leak-check=full --trace-children=yes sched_getattr02" contacts="" analysis=exit <<<test_output>>> --24040-- WARNING: unhandled amd64-linux syscall: 315 --24040-- You may be able to write your own handler. --24040-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --24040-- Nevertheless we consider this a bug. Please report --24040-- it at http://valgrind.org/support/bug_reports.html. --24040-- WARNING: unhandled amd64-linux syscall: 315 --24040-- You may be able to write your own handler. --24040-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --24040-- Nevertheless we consider this a bug. Please report --24040-- it at http://valgrind.org/support/bug_reports.html. --24040-- WARNING: unhandled amd64-linux syscall: 315 --24040-- You may be able to write your own handler. --24040-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --24040-- Nevertheless we consider this a bug. Please report --24040-- it at http://valgrind.org/support/bug_reports.html. --24040-- WARNING: unhandled amd64-linux syscall: 315 --24040-- You may be able to write your own handler. --24040-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --24040-- Nevertheless we consider this a bug. Please report --24040-- it at http://valgrind.org/support/bug_reports.html. sched_getattr02 1 TFAIL : sched_getattr02.c:83: sched_getattr() failed unexpectedly : expected: 3 - ESRCH: TEST_ERRNO=ENOSYS(38): Function not implemented sched_getattr02 2 TFAIL : sched_getattr02.c:83: sched_getattr() failed unexpectedly : expected: 22 - EINVAL: TEST_ERRNO=ENOSYS(38): Function not implemented sched_getattr02 3 TFAIL : sched_getattr02.c:83: sched_getattr() failed unexpectedly : expected: 22 - EINVAL: TEST_ERRNO=ENOSYS(38): Function not implemented sched_getattr02 4 TFAIL : sched_getattr02.c:83: sched_getattr() failed unexpectedly : expected: 22 - EINVAL: TEST_ERRNO=ENOSYS(38): Function not implemented <<<execution_status>>> initiation_status="ok" duration=1 termination_type=exited termination_id=1 corefile=no cutime=68 cstime=2 <<<test_end>>> Reproducible: Always
Can we close it? IIRC it was merged into valgrind.
I have created a crude patch to support sched_getattr and sched_setattr under linux. I am using Debian GNU/Linux x86_64. If those in the know can take a look and tidy it up and merge it into the source repository, that would be great. I am going to upload the patch, a simple test program I created, test log, and manual of sched_getattr/sched_setattr for reference.
Created attachment 127553 [details] Patch to support sched_getattr and sched_setattr. This is the patch for linux (x86_64) created and test under Debian GNU/Linux.
Created attachment 127554 [details] A test program to test the operation of sched_getattr() and sched_setattr(). A simple program that I used to test the support of sched_getattr and sched_setattr by patched valgrind.
Created attachment 127555 [details] Log of running the test program under the patched valgrind. Log of the program. In the case of passing the structure mentioned in the manual page, and exact size, the initialization status of memory buffer returned is as expected. However, if I pass a large buffer (with 1024 octet size), the underlying system call seems to use block copy (16 octets at a time) and I seem to have a memory buffer returned with a few extra octets initialized. Not fatal, and probably a feature. Just interesting.
I needed to implement the support for these two system calls because somehow I found that running thunderbird under valgrind for mozilla test suite called mochitest forced valgrind to create so many tasks (> 1500) and it blew up. (--max-threads=1500 did not help.) I filed a bug at mozilla bugzilla. See https://bugzilla.mozilla.org/show_bug.cgi?id=1629433 Running thunderbird binary under valgrind while trying to run mochitest requires way TOO MANY threads (> 1500) !? Now that the supporting these system calls via this patch does not seem to change the blowup behavior. Now I have a feeling that there are so many tasks created related to futex_wait_cancellable (related to syscall 202), I feel there is a bug in the handling futex calls under x86_64 linux, but then I am not sure why we don't hear from Firefox people about the similar problem... Anyway merging of the tidied up patch to the source repository of valgrind will be appreciated. If also, someone can take a look at the log posted at mozilla bugzilla See https://bugzilla.mozilla.org/show_bug.cgi?id=1629433 and shed some light on the issue, I would appreciate it very much. TIA
Created attachment 127556 [details] manual page of sched_getattr and sched_setattr from Debian GNU/Linux Here is the copy of man page of the sched_getattr and sched_setattr calls.
*** Bug 405394 has been marked as a duplicate of this bug. ***
*** Bug 422417 has been marked as a duplicate of this bug. ***
*** Bug 423095 has been marked as a duplicate of this bug. ***
I think I need to merge the patch from 405394 into the patch here and then the patch would be complete. Let me remind myself to do this next weekend.
Created attachment 130422 [details] Cleaned up patch from bug #405394 (In reply to zephyrus00jp from comment #11) > I think I need to merge the patch from 405394 into the patch here and then > the patch would be complete. Let me remind myself to do this next weekend. I took your patch and cleaned it up a little. Differences are: - hooked up all linux arches - Removed POST handler for sched_setattr (as far as I can see, the kernel only reads from the struct sched_attr, but doesn't write anything back) - Added a ML_(safe_to_deref) call before reading attr->size (so we don't crash if the user passes in NULL or a bogus address) - Use the actual attr->size as the memory that must/will be initialized (since the actual struct size could differ in the future).
(In reply to Mark Wielaard from comment #12) > Created attachment 130422 [details] > Cleaned up patch from bug #405394 > > (In reply to zephyrus00jp from comment #11) > > I think I need to merge the patch from 405394 into the patch here and then > > the patch would be complete. Let me remind myself to do this next weekend. > > I took your patch and cleaned it up a little. Differences are: > - hooked up all linux arches > - Removed POST handler for sched_setattr (as far as I can see, the kernel > only reads from the struct sched_attr, but doesn't write anything back) > - Added a ML_(safe_to_deref) call before reading attr->size (so we don't > crash if the user passes in NULL or a bogus address) > - Use the actual attr->size as the memory that must/will be initialized > (since the actual struct size could differ in the future). Thank you for the cleanup. I wonder what the merge plan/policy is.
(In reply to zephyrus00jp from comment #13) > Thank you for the cleanup. > > I wonder what the merge plan/policy is. Currently testing the patch for the Fedora rawhide valgrind package. Looking good. If nobody objects I'll merge it end of the week.
commit 6323fd5bfd94c3f80e2ff44f16488e0172bd9a96 Author: Mark Wielaard <mark@klomp.org> Date: Mon Jul 27 16:36:17 2020 +0200 Handle linux syscalls sched_getattr and sched_setattr The only "special" thing about these syscalls is that the given struct sched_attr determines its own size for future expansion. Original fix by "ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp> https://bugs.kde.org/show_bug.cgi?id=369029
*** Bug 425422 has been marked as a duplicate of this bug. ***
*** Bug 425967 has been marked as a duplicate of this bug. ***
*** Bug 430597 has been marked as a duplicate of this bug. ***
Funny, I still get this under linux amd64. > 44:03.61 GECKO(32022) --32026-- WARNING: unhandled amd64-linux syscall: 315 Doesn't valgrind 3.16.1 have this patch yet? TIA
(In reply to zephyrus00jp from comment #20) > Funny, I still get this under linux amd64. > > > 44:03.61 GECKO(32022) --32026-- WARNING: unhandled amd64-linux syscall: 315 > > Doesn't valgrind 3.16.1 have this patch yet? If your distro has backported (like Fedora) yes. Otherwise, please try the valgrind 3.17.0 RC releases.
*** Bug 369028 has been marked as a duplicate of this bug. ***
*** Bug 368919 has been marked as a duplicate of this bug. ***
*** Bug 368920 has been marked as a duplicate of this bug. ***