[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-07-04 Thread Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=317127 Paul Floyd changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|---

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-07-04 Thread Mark Wielaard
https://bugs.kde.org/show_bug.cgi?id=317127 --- Comment #22 from Mark Wielaard --- Created attachment 171372 --> https://bugs.kde.org/attachment.cgi?id=171372&action=edit Avoid dev/inode check on btrfs with --sanity-level=3 With --sanity-level=3 or higher the aspacemgr sanity checks the device

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-07-03 Thread Mark Wielaard
https://bugs.kde.org/show_bug.cgi?id=317127 --- Comment #21 from Mark Wielaard --- Could we make it linux generic by just using __NR_statfs and struct statfs (which seems defined for each linux arch already): diff --git a/coregrind/m_aspacemgr/aspacemgr-linux.c b/coregrind/m_aspacemgr/aspacemgr-

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-06-30 Thread Mark Wielaard
https://bugs.kde.org/show_bug.cgi?id=317127 Mark Wielaard changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-05-08 Thread Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=317127 --- Comment #19 from Paul Floyd --- (In reply to Mark Wielaard from comment #18) > I must admit I don't fully understand what we are trying to do. As far as I > understand it, the idea is that we sanity check what the aspacemgr records > against what /p

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-05-08 Thread Mark Wielaard
https://bugs.kde.org/show_bug.cgi?id=317127 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #18 from Mark Wielaa

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-05-06 Thread Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=317127 Paul Floyd changed: What|Removed |Added Assignee|jsew...@acm.org |pjfl...@wanadoo.fr -- You are receiving this mail

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-05-06 Thread Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=317127 --- Comment #17 from Paul Floyd --- And with the patch I get a clean slate == 880 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == -- You are receiving this mail because: You are watching all bug

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-05-06 Thread Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=317127 --- Comment #16 from Paul Floyd --- The patch I just added seems to work OK. There is a plan B. In the patch I've also updated the statx structure which (since kernel 5.8) has an stx_mnt_id which we could try to use. I don't know how many people are st

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-05-06 Thread Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=317127 --- Comment #15 from Paul Floyd --- Created attachment 169247 --> https://bugs.kde.org/attachment.cgi?id=169247&action=edit patch, amd64 only Initial version of a fix. -- You are receiving this mail because: You are watching all bug changes.

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-05-06 Thread Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=317127 --- Comment #14 from Paul Floyd --- I think that the answer is to add something like VG_(do_syscall3)(__NR_statfs, filename, &statfs); if (statfs.f_type == BTRFS_SUPER_MAGIC) { cmp_devino = False; } inside the existing VGO_linux block. -- You are

[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch

2024-05-06 Thread Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=317127 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #13 from Paul Floyd