https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #19 from Samuel Thibault ---
(ran it for an hour)
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #18 from Samuel Thibault ---
I have run the reproducer on all the various systems previously mentioned, with
no issue so far, so it seems we're good with that fix.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #17 from Samuel Thibault ---
Ah, configure.ac already detects which case that is. So we need a valgrind
built against the proper glibc, that's why I hadn't the proper name.
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #16 from Samuel Thibault ---
> I would expect these to be covered by the default suppressions:
> {
>helgrind-glibc2X-004
>Helgrind:Race
>obj:*/lib*/libc-2.*so*
> }
Ah, but glibc renamed libc-2.*so* into
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #14 from Samuel Thibault ---
FYI, it's glibc 2.36:
- pthread_mutex_lock.c:94 is when it checks assert (mutex->__data.__owner ==
0); after obtaining the lock
- pthread_mutex_lock.c:182 is when it sets mutex->__data.__owner after
obt
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #12 from Samuel Thibault ---
Yes that avoids that exact issue, but then a flurry of new ones pop up, I was
not getting them before:
==2511392== Possible data race during read of size 4 at 0x10C128 by thread #2
==2511392== Locks held: none
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #8 from Samuel Thibault ---
(with the various versions of valgrind between 3.9 and 3.19)
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=327548
Samuel Thibault changed:
What|Removed |Added
Resolution|WORKSFORME |---
Ever confirmed|0
