Bug 480052 - WARNING: unhandled amd64-freebsd syscall: 580
Summary: WARNING: unhandled amd64-freebsd syscall: 580
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.22 GIT
Platform: FreeBSD Ports FreeBSD
: NOR normal
Target Milestone: ---
Assignee: Paul Floyd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-01-19 17:11 UTC by asomers
Modified: 2024-01-21 19:47 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description asomers 2024-01-19 17:11:22 UTC
SUMMARY

memcheck does not handle the "fspacectl" syscall (syscall #580).


STEPS TO REPRODUCE
1.  Using FreeBSD 14/stable, 15.0-CURRENT, or 14.0-RELEASE with the tests distribution installed:
2.  cd /usr/tests/sys/fs/fusefs
3. valgrind --tool=memcheck ./fallocate --gtest_filter=Fspacectl.ok -v

OBSERVED RESULT

==14536== Memcheck, a memory error detector
==14536== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==14536== Using Valgrind-3.22.0.GIT and LibVEX; rerun with -h for copyright info
==14536== Command: ./fallocate --gtest_filter=Fspacectl.ok -v
==14536== 
Note: Google Test filter = Fspacectl.ok
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from Fspacectl
[ RUN      ] Fspacectl.ok
INIT        ino= 0
ACCESS      ino= 1 mask=0x1
LOOKUP      ino= 1 some_file.txt
OPEN        ino=42 flags=0x2
--14536-- WARNING: unhandled amd64-freebsd syscall: 580
--14536-- You may be able to write your own handler.
--14536-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--14536-- Nevertheless we consider this a bug.  Please report
--14536-- it at http://valgrind.org/support/bug_reports.html.
/usr/home/somers/src/freebsd.org/src/tests/sys/fs/fusefs/fallocate.cc:335: Failure
Expected equality of these values:
  0
  fspacectl(fd, 1, &rqsr, 0, &rmsr)
    Which is: -1

EXPECTED RESULT

The test should pass

SOFTWARE/OS VERSIONS
FreeBSD 14.0-RELEASE and later.

ADDITIONAL INFORMATION
Comment 1 Paul Floyd 2024-01-20 07:01:05 UTC
This should be in FreeBSD 13.1+

580	AUE_FSPACECTL	STD|CAPENABLED {
		int fspacectl(
		    int fd,
		    int cmd,
		    _In_ const struct spacectl_range *rqsr,
		    int flags,
		    _Out_opt_ struct spacectl_range *rmsr,
Comment 2 asomers 2024-01-20 14:07:11 UTC
No, it isn't in 13.1.  It first appeared in 14.0.  You can check from the man pages browser here: https://man.freebsd.org/cgi/man.cgi?query=fspacectl .
Comment 3 Paul Floyd 2024-01-20 17:58:28 UTC
Bah yes. Syscall 580 was a hole in the numbering until FreeBSD 14.
Comment 4 Paul Floyd 2024-01-20 20:20:07 UTC
The missing syscall should be fixed with

commit 3cacde0ca261196031cb84b22ad427483bae057e (HEAD -> master, origin/master, origin/HEAD)
Author: Paul Floyd <pjfloyd@wanadoo.fr>
Date:   Sat Jan 20 21:14:37 2024 +0100

    Bug 480052 - WARNING: unhandled amd64-freebsd syscall: 580

I still get a lot of errors and the googletest fails
Comment 5 asomers 2024-01-20 23:52:00 UTC
Thanks for the quick fix!  It works for me.  As for the other failures, they seem unrelated.  It seems like the server thread (there are two threads) hangs when reading from /dev/fuse.  The hangs only happen with some test cases and not others.  I can't see any pattern behind which test cases hang and which don't.  Is there any way that valgrind could introduce a deadlock?  Perhaps the read from /dev/fuse triggers a signal, but the signal handler can't run because the first thread is blocked in the fspacectl syscall?
Comment 6 Paul Floyd 2024-01-21 19:47:20 UTC
Valgrind is unlikely to cause a deadlock.

However, it can bring out race conditions. Firstly, it is considerably slower. Secondly, it runs effectively as though there were a single CPU (similar to Python and its GIL). So code that works by accident because one thread 'always' does something before another can get caught out.