SUMMARY

After upgrading my Linux from Ubuntu 18.04 LTS to Ubuntu 20.04 LTS, I started getting unexpected warnings while inspecting a custom program written in C/C++ with valgrind which previously ran fine (i.e., no error nor warning issued by valgrind with --leak-check=full). These warnings state that there are two unhandled syscalls 403 and 407. Such warnings don't prevent completion of the program nor induce errors regarding its behaviour, but are annoying as a display. It is especially the case for 407: this warning seems to be due to the usleep() function which I use regularly for slightly delaying some tasks in my program (see ADDITIONAL INFORMATION).

Following the suggestion of the error message, I had a quick look at README_MISSING_SYSCALL_OR_IOCTL text file, which suggests writing my own wrappers for the given syscalls. However, since the problem is still mentioned as a bug by valgrind ("Nevertheless we consider this a bug. Please report [...]") and as it only occurred to me after right moving to Ubuntu 20.04, I preferred to first advertise it here.

After closer inspection, it turns out the problem seems to be tied to timing functions which might have been updated while moving from Ubuntu 18.04 to Ubuntu 20.04. Indeed, what appear to be the corresponding functions in valgrind source code (i.e., in coregrind/m_syswrap/) aren't suffixed by "64" like in my case (see ADDITIONAL INFORMATION). I get respectively "unhandled syscall 403" for time()/localtime() and I am rather confident I get "unhandled syscall 407" because of the usleep() method of unistd.h (again, see ADDITIONAL INFORMATION).

This is the (requested) display of uname -a:

Linux jefgrailet-ThinkPad-T410 5.4.0-37-generic #41-Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Because my console output with valgrind -v is huge (there are several memory allocations at the start of my program), I only copy/pasted the relevant parts below.

Note that I (naively) tried to fix this by removing valgrind and re-installing it through the apt command, as I first believed valgrind didn't got properly upgraded while upgrading Ubuntu. I still got the same issues afterwards.

Many thanks in advance for considering this report.

STEPS TO REPRODUCE

(for getting "unhandled syscall 403")

1. Write a short C/C++ program using the time() and localtime() functions. These instructions (getting the current time then writing it in a string) should do the trick:

time_t rawTime;
struct tm *timeInfo;
char buffer[80];

time(&rawTime);
timeInfo = localtime(&rawTime);

strftime(buffer, 80, "%d-%m-%Y %T", timeInfo);
string timeStr(buffer); // Can be displayed right after

2. Run it with valgrind without any specific flag.

OBSERVED RESULT

(upon getting "unhandled syscall 403")

Valgrind appends the following warning in the console each time I'm using the time()/gettime() functions from time.h:

[...]
--3119-- WARNING: unhandled x86-linux syscall: 403
--3119-- You may be able to write your own handler.
--3119-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--3119-- Nevertheless we consider this a bug.  Please report
--3119-- it at http://valgrind.org/support/bug_reports.html.
[...]

EXPECTED RESULT

(still regarding "unhandled syscall 403")

There should be no such warning, as the time manipulations I do work as intended. The code given above still displays the correct date and time for me.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Ubuntu 20.04 (LTS)

ADDITIONAL INFORMATION

Using the following commands recommended by the README_MISSING_SYSCALL_OR_IOCTL text file, this is the output I get:

$ grep 403 /usr/include/asm/unistd*.h
/usr/include/asm/unistd_32.h:#define __NR_clock_gettime64 403
$ grep 407 /usr/include/asm/unistd*.h
/usr/include/asm/unistd_32.h:#define __NR_clock_nanosleep_time64 407

Regarding unhandled syscall 407, if I use "valgrind -v" on my program, this appears and explicitely mentions the usleep() function:

[...]
--3896-- WARNING: unhandled x86-linux syscall: 407
==3896==    at 0x4C4C5ED: __GI___clock_nanosleep_time64 (clock_nanosleep.c:52)
==3896==    by 0x4C4C6D1: clock_nanosleep@@GLIBC_2.17 (clock_nanosleep.c:92)
==3896==    by 0x4C53153: nanosleep (nanosleep.c:27)
==3896==    by 0x4C872B4: usleep (usleep.c:32)
[...]