https://bugs.kde.org/show_bug.cgi?id=327548
Paul Floyd changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
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 just libc.so.6, so that
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #15 from Paul Floyd ---
(In reply to Samuel Thibault from comment #12)
> 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
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
obtaining
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #13 from Paul Floyd ---
Looking at the glibc source
pthread_mutex_destroy is fairly simple. It does an atomic read of the kind and
a plain read of nusers and returns EBUSY if nusers is not 0.
It then sets kind to an invalid value, -1.
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 #11 from Paul Floyd ---
This is the same as what Philippe suggested in the e-mail thread, but with
similar protection for cond vars.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #10 from Paul Floyd ---
Can you try this patch please?
diff --git a/helgrind/hg_intercepts.c b/helgrind/hg_intercepts.c
index 5a83996..8c98e4e 100644
--- a/helgrind/hg_intercepts.c
+++ b/helgrind/hg_intercepts.c
@@ -879,7 +879,9 @@ static
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #9 from Paul Floyd ---
I can reproduce this on a RHEL 7.6 machine.
--
You are receiving this mail because:
You are watching all bug changes.
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
https://bugs.kde.org/show_bug.cgi?id=327548
Paul Floyd changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=327548
--- Comment #5 from Paul Floyd ---
I ran this for a couple of hours without any errors. It could be related to the
hardware.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=327548
Paul Floyd changed:
What|Removed |Added
CC||pjfl...@wanadoo.fr
--- Comment #4 from Paul Floyd
17 matches
Mail list logo
