Control: retitle -1 valgrind: Access not within mapped region on armhf Hello Paul and Julian, On 2023-12-24 07:31, Paul Gevers wrote: > On 23-12-2023 20:40, Julian Andres Klode wrote: > > the logs for well known bugs so that you don't end up filing bugs > > against every package broken by valgrind's missing support for the new > > NOP sequences in binutils. > > I do *some* minor triaging, but I didn't know this to be a common problem. Note that there are three distinct valgrind problems mentioned here: - on armhf, flagging accesses below the stack pointer as illegal. This came up after enabling stack-clash-protection on armhf. I added a suppression for this problem in valgrind 1:3.20.0-2, so we shouldn't be seeing those anymore. For reference: https://lists.debian.org/debian-arm/2023/12/msg00007.html - on i386, valgrind was failing due to new nop patterns that it didn't know about. This is https://bugs.debian.org/1057693 and was fixed by Aurelien in 1:3.20.0-2.1 - on armhf, a segfault when testing apt. I don't think this issue is widespread at all: in fact I'm not aware of any other instances except for apt. After going through all armhf CI failures caused by segfaults, apt seems to be the only one with valgrind in the picture. Just to be clear: I'm not saying that the problem is trivial, just that AFAIK it's not widespread. I'm including the relevant CI logs below for reference. Also I'm attaching the horrible script I've written to fetch all armhf CI failures in case anyone wants to poke around. 722s ==221367== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. 722s ==221367== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info 722s ==221367== Command: /usr/bin/apt-get update -o Acquire::Queue-Mode=access 722s ==221367== 722s ==221367== 722s ==221367== Process terminating with default action of signal 11 (SIGSEGV) 722s ==221367== Access not within mapped region at address 0xFE7F2A9C 722s ==221367== at 0x4938838: ReadMessages(int, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) (in /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.6.0.0) 722s ==221367== If you believe this happened as a result of a stack 722s ==221367== overflow in your program's main thread (unlikely but 722s ==221367== possible), you can try to increase the size of the 722s ==221367== main thread stack using the --main-stacksize= flag. 722s ==221367== The main thread stack size used in this run was 8388608. 722s ==221367== 722s ==221367== HEAP SUMMARY: 722s ==221367== in use at exit: 119,915 bytes in 1,882 blocks 722s ==221367== total heap usage: 11,673 allocs, 9,791 frees, 868,849 bytes allocated 722s ==221367== 722s ==221367== LEAK SUMMARY: 722s ==221367== definitely lost: 0 bytes in 0 blocks 722s ==221367== indirectly lost: 0 bytes in 0 blocks 722s ==221367== possibly lost: 0 bytes in 0 blocks 722s ==221367== still reachable: 119,915 bytes in 1,882 blocks 722s ==221367== suppressed: 0 bytes in 0 blocks 722s ==221367== Rerun with --leak-check=full to see details of leaked memory 722s ==221367== 722s ==221367== For lists of detected and suppressed errors, rerun with: -s 722s ==221367== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 42821 from 965) 722s Segmentation fault 722s FAIL: exitcode 139
Attachment:
armhf-ci-segfaults.sh
Description: Bourne shell script