https://bugs.kde.org/show_bug.cgi?id=502126
Bug ID: 502126
Summary: glibc 2.41 extra syscall_cancel frames
Classification: Developer tools
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: m...@klomp.org
CC: ahajk...@redhat.com, f...@deneb.enyo.de,
zatr...@gmail.com
Target Milestone: ---
Since glibc 2.41 there are extra frames inserted before doing a syscall to
support proper thread cancellation.
This breaks various suppressions and regtests involving checking syscall
arguments.
As example the memcheck/test/sendmsg
Before glibc 2.41
==1929378== Syscall param sendmsg(msg) points to uninitialised byte(s)
==1929378== at 0x4971514: sendmsg (sendmsg.c:28)
==1929378== by 0x40128B: main (sendmsg.c:46)
==1929378== Address 0x1ffefff640 is on thread 1's stack
==1929378== in frame #1, created by main (sendmsg.c:13)
After it looks like:
==2670784== Syscall param sendmsg(msg) points to uninitialised byte(s)
==2670784== at 0x48D9AE6: __internal_syscall_cancel (cancellation.c:64)
==2670784== by 0x48D9B03: __syscall_cancel (cancellation.c:75)
==2670784== by 0x49628F0: sendmsg (sendmsg.c:28)
==2670784== by 0x4005CB: main (sendmsg.c:46)
==2670784== Address 0x1ffeffff40 is on thread 1's stack
==2670784== in frame #3, created by main (sendmsg.c:13)
There is also __syscall_cancel_arch which shows up in some gdb_server
testcases.
Mailinglist discussion:
https://inbox.sourceware.org/libc-alpha/4954a5131faf35cbe4d88ac7729a1fa3ba4b2cb8.ca...@klomp.org/T/#t
Proposal is to filter out those extra top frames early when the platform is
VGO_linux and we are handling PRE/POST syscalls.
There is still an open question whether there is any impact from these
functions doing tail calls, which might hide the actual caller frame. This
should be solved on the glibc side.
--
You are receiving this mail because:
You are watching all bug changes.
