https://bugs.kde.org/show_bug.cgi?id=345307
Philippe Waroquiers changed:
What|Removed |Added
Status|CONFIRMED |RESOLVED
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #34 from Philippe Waroquiers ---
(In reply to Philippe Waroquiers from comment #32)
> As I understand, the problem is 'cleanly' fixed in a newer version of glibc,
> by having valgrind calling
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #33 from Philippe Waroquiers ---
(In reply to Philippe Waroquiers from comment #32)
> The workaround is either to just ignore the test failure, or add a
> suppression entry (see comment 5).
Typo : see rather
https://bugs.kde.org/show_bug.cgi?id=345307
Philippe Waroquiers changed:
What|Removed |Added
CC|
https://bugs.kde.org/show_bug.cgi?id=345307
Aleksandar Rikalo changed:
What|Removed |Added
Attachment #102559|0 |1
is
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #30 from Aleksandar Rikalo ---
Patch from #373069 has been committed.
Now we need just https://bugs.kde.org/attachment.cgi?id=102559 to make
memcheck/leak_cpp_interior pass with gcc-6.
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #29 from Aleksandar Rikalo ---
Can anyone take a look on this?
Thank you in advance!
Aleksandar
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=345307
Petar Jovanovic changed:
What|Removed |Added
CC||mips3...@gmail.com
--
https://bugs.kde.org/show_bug.cgi?id=345307
Aleksandar Rikalo changed:
What|Removed |Added
CC|
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #27 from Ivo Raisr ---
Status:
- Fixed for libstdc++ from gcc 6.
- Not fixed for libstdc++ from gcc 5 because they won't accept a new public
symbol there. You can use a workaround from comment #15.
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #26 from Ivo Raisr ---
Followup fix for x86 architecture: SVN r15854.
Failed test case was memcheck/tests/addressable built as 32-bit executable
which showed:
Conditional jump or move depends on uninitialised value(s)
https://bugs.kde.org/show_bug.cgi?id=345307
Nicholas Fraser changed:
What|Removed |Added
CC|nicholas.rd.fra...@gmail.co |
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #25 from Mark Wielaard ---
(In reply to Anatolik from comment #24)
> Is this bug fixed for gcc5?
No.
You might try using the libstdc++.supp as a workaround for now.
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=345307
Anatolik changed:
What|Removed |Added
CC||anatol.pomo...@gmail.com
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #23 from Ivo Raisr ---
Fixed in SVN r15840, for gcc 6.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #22 from Ivo Raisr ---
The first issue is fixed by SVN r15839.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #21 from Ivo Raisr ---
There is some backgroud for memcheck/tests/reach_thread_register:
https://bugs.kde.org/show_bug.cgi?id=324227
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #20 from Ivo Raisr ---
Mark, thank you for review.
However I found two problems with the patch (v3):
- memcheck/tests/reach_thread_register fails on amd64/Solaris
- freeres wrapper is called on Solaris, even if there is no
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #19 from Mark Wielaard ---
I did some quick tests with this patch on x86, x86_64, arm, s390x, ppc64,
ppc64le and arm64. None of those setups had the new libstdc++ hook yet, but all
had glibc. So it seems the new code
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #18 from Mark Wielaard ---
The patch looks good to me and work as expected on GNU/Linux x86_64 with
libstdc++ from gcc trunk.
I don't have much experience with the different architecture function call
arguments. But it
https://bugs.kde.org/show_bug.cgi?id=345307
Ivo Raisr changed:
What|Removed |Added
Attachment #98117|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=345307
Ivo Raisr changed:
What|Removed |Added
Attachment #97556|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #15 from Mark Wielaard ---
Created attachment 97829
--> https://bugs.kde.org/attachment.cgi?id=97829=edit
libstdc++.supp
This is the patch the valgrind fedora package is currently using as a
workaround till we get proper
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #14 from Ivo Raisr ---
My apologies, we were talking about different things which just now I realized.
Now I understand you are talking about VG_USERREQ__LIBC_FREERES_DONE client
request
whereas I was talking about
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #13 from Mark Wielaard ---
(In reply to Ivo Raisr from comment #11)
> Yes, it can be done with just one FREERES_DONE hook.
> But it means we need to pass argument(s) to it (which __freeres functions to
> call) and this will
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #12 from Ivo Raisr ---
At the moment we are waiting on libstdc++ changes which need to materialize
first.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #11 from Ivo Raisr ---
Yes, it can be done with just one FREERES_DONE hook.
But it means we need to pass argument(s) to it (which __freeres functions to
call) and this will involve some extra code for all supported
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #10 from Mark Wielaard ---
The __gnu_cxx::__freeres patch looks really good. I have been testing it with
the gcc patch on x86_64-pc-linux-gnu. And things look fine. No more still
reachable leaks.
Only question is whether
https://bugs.kde.org/show_bug.cgi?id=345307
Mark Wielaard changed:
What|Removed |Added
CC||m...@redhat.com
--
You are
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #9 from Ivo Raisr ---
Regression testing on Linux and Solaris went fine.
Together with patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945
we see now:
==1862== HEAP SUMMARY:
==1862== in use at exit: 0 bytes in
https://bugs.kde.org/show_bug.cgi?id=345307
--- Comment #8 from Ivo Raisr ---
Created attachment 97556
--> https://bugs.kde.org/attachment.cgi?id=97556=edit
patch for Linux and Solaris calling __gnu_cxx::__freeres from libstdc++
This is fix for the Valgrind side.
Fix for
31 matches
Mail list logo