Re: [Valgrind-users] valgrind gets fatal signal when particular syscall is made by an executable

[John R. <jr...@bi...>]

> On a machine that has an old linux kernel, when valgrind 3.21.0 runs an
> executable that contains a call to syscall 378 - valgrind fails after
> being killed by a fatal signal.
> 
> The kernel on the machine is 3.10.0 x86_64 (the system is based on RedHad 5,
> I think), libc 2.17, and the executable itself is 32 bit.

Please show the complete output of "uname -a".
In the linux git source code repository
   url = git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
there is no git tag "v3.10.0"; only "v3.10" and "v3.10.1", "v3.10.2", etc.

> On this particular kernel, syscall 378 happens to be mapped to setprocns,

After checking out the code via "git checkout v3.10.1", then "grep -sr setprocns ."
shows that the linux source code has no lines that contain "setprocns".
So there is an error in part of your claim.

> valgrind thinks that an executable is trying to execute syscall preadv2, which
> is indeed mapped to 378 on newer kernels, but doesn't exist in linux 3.10.0

It is correct that "grep -sr preadv2 ." shows no matching lines in linux v3.10.1.
However, "cd arch/x86; grep -sr 378 ." shows no syscall numbered 378.
Please verify what you are talking about.

"cd arch/x86; grep -sr setns ." does show these syscalls with a related name:
./syscalls/syscall_64.tbl:308	common	setns			sys_setns
./syscalls/syscall_32.tbl:346	i386	setns			sys_setns

> Older versions of valgrind (for example, valgrind 3.10.0) don't have this
> problem, and succeed to execute the same executable on this machine.

Therefore one solution is to use a version of valgrind that is contemporaneous
with your kernel.  Check the list of versions and dates for both linux and
valgrind, and find the best match.

> What can I do to fix the problem? Unfortunately I am stuck with having to
> use such an old system, and therefore using newer kernel is not an option.

1. Double check the versions that you claim, and prove against the official sources.
2. The valgrind syscall table is in coregrind/m_syswrap/syswrap-x86-linux.c
    and syswrap-amd64-linux.c.  Therefore, modify the source code of valgrind
    to call utsname() during initialization, and alter the table
       static SyscallTableEntry syscall_table[] = { ... };
    accordingly.  Probably 'static' must be removed.  Also, 'const' should
    be removed if necessary.  [Why isn't the table 'const' in the first place?]

Note that any change in syscall numbers creates a giant incompatibility
for any app that is built using "the other" assignments.  No old apps
can be relied to run on newer systems, and no new apps can be relied
to run on older systems.  That's a disaster, and it is *NOT* "waiting to
happen"; it has already happened.