Re: [Valgrind-users] new error message from Valgrind

[Tom H. <to...@co...>]

No, it's clone3:

https://bugs.kde.org/show_bug.cgi?id=420906

Tom

On 03/08/2022 17:30, Mark Roberts wrote:
> Just tried running the Valgrind test suite on WSL2 (win 10, Ubuntu 22.04).
> I'm not surprised that there were lots of failures.  But the majority were:
> WARNING: unhandled amd64-linux syscall: 435
> 
> I suspect WSL is not a platform you care much about, but looking at syswrap
> for Darwin I see this might be pid hibernate?  Would it be difficult to add
> support for this?
> 
> Thank you,
> Mark
> 
> -----Original Message-----
> From: Mark Wielaard [mailto:ma...@kl...]
> Sent: Monday, August 1, 2022 4:56 AM
> To: Tom Hughes <to...@co...>; Mark Roberts <ma...@cs...>;
> val...@li...
> Subject: Re: [Valgrind-users] new error message from Valgrind
> 
> On Thu, 2022-07-28 at 22:22 +0100, Tom Hughes via Valgrind-users wrote:
>> On 28/07/2022 21:39, Mark Roberts wrote:
>>> I recently upgraded from Ubutu 20.04 to 22.04 and am now getting a
>>> new error message from Valgrind:
>>>
>>> --915-- WARNING: unhandled amd64-linux syscall: 334
>>>
>>> --915-- You may be able to write your own handler.
>>>
>>> --915-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
>>>
>>> --915-- Nevertheless we consider this a bug.  Please report
>>>
>>> --915-- it at http://valgrind.org/support/bug_reports.html
>>> <http://valgrind.org/support/bug_reports.html>.
>>>
>>> Using same version of Valgrind as before (3.17).
>>>
>>> Any ideas as to what’s happening?
>>
>> Yes, your libc has started trying to use rseq.
>>
>> It's harmless - the next version of valgrind will silently reject it
>> with ENOSYS which is what is happening now anyway just with a warning.
> 
> Where the next version of valgrind is 3.19.0 which is already released (in
> April).  So you might just want to upgrade your valgrind.
> 
> If you want to backport to older versions then the commit that got rid of
> the warning was:
> 
> commit 1024237358f01009fe233cb1294f3b8211304eaa
> Author: Mark Wielaard <ma...@kl...>
> Date:   Fri Dec 10 17:41:59 2021 +0100
> 
>      Implement linux rseq syscall as ENOSYS
> 
>      This implements rseq for amd64, arm, arm64, ppc32, ppc64,
>      s390x and x86 linux as ENOSYS (without warning).
> 
>      glibc will start using rseq to accelerate sched_getcpu, if
>      available. This would cause a warning from valgrind every
>      time a new thread is started.
> 
>      Real rseq (restartable sequences) support is pretty hard, so
>      for now just explicitly return ENOSYS (just like we do for clone3).
> 
> 
> https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html
> 
> Cheers,
> 
> Mark


-- 
Tom Hughes (to...@co...)
http://compton.nu/