https://bugs.kde.org/show_bug.cgi?id=444481
Andreas Arnez <ar...@linux.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ar...@linux.ibm.com
--- Comment #1 from Andreas Arnez <ar...@linux.ibm.com> ---
I've investigated the failure with nlvgdbsigqueue, and here's what I found out
so far.
The failure happens when trying to continue execution from an unmapped address:
+host stacktrace:
+ at 0x3FFBAF7E480: ???
+ by 0x800027FE7: vgPlain_poll (m_libcfile.c:765)
+ by 0xFFFFFFFFFFFFFFFF: ???
It turns out that the failing address, in this case 0x3FFBAF7E480, lies within
the address range that previously held the vDSO. The kernel seems to jump there
when restarting a "poll" syscall after a signal occurred. But Valgrind doesn't
keep the vDSO mapping, so the syscall restart doesn't work and causes a SIGSEGV
instead.
So, why and since when does the kernel jump to the vDSO? This has obviously
been introduced by this s390-specific patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df29a7440c4b5c65765c8f60396b3b13063e24e9
Considering this change in the kernel's behavior, it now becomes necessary for
all user space processes to keep the vDSO mapping intact, and Valgrind
currently violates that.
--
You are receiving this mail because:
You are watching all bug changes.
