| Summary: | gdb_server test failures on s390x | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Mark Wielaard <mark> |
| Component: | general | Assignee: | Andreas Arnez <arnez> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arnez |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=441474 | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | 441474 | ||
| Bug Blocks: | |||
| Attachments: | Keep vDSO mapping on s390x | ||
|
Description
Mark Wielaard
2021-10-27 12:02:14 UTC
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. Created attachment 144394 [details]
Keep vDSO mapping on s390x
In my testing this patch fixes the issue. Some other architectures already have similar logic to keep the vDSO mapping intact. Note that this shouldn't affect the AUXV entry for the vDSO, which should still be removed from the AUXV.
(In reply to Andreas Arnez from comment #2) > [...] Note that this shouldn't > affect the AUXV entry for the vDSO, which should still be removed from the > AUXV. Oops, that's not true. This version of the patch leaves the AUXV entry intact as well. Sorry for the confusion. Applied as commit 99bf5dabf7865aaea7f2192373633e026c6fb16e. Thanks. Tests look good. |