https://bugs.kde.org/show_bug.cgi?id=356457
--- Comment #20 from Philippe Waroquiers ---
Yet another trial you can do (if you try the svn version) is to activate
DEBUG_MALLOC
in coregrind/m_mallocfree.c file.
This might give a chance to detect a possible corruption closer to the origin
of the cor
https://bugs.kde.org/show_bug.cgi?id=356457
--- Comment #19 from Philippe Waroquiers ---
(In reply to Eric Chamberland from comment #18)
> which corresponds to one of the 6 failling tests of last night.
For these 6 failing tests (or the failing tests of the other runs)
is it always (or often ?)
https://bugs.kde.org/show_bug.cgi?id=369468
Philippe Waroquiers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=369468
Philippe Waroquiers changed:
What|Removed |Added
Summary|Implement |Implement HT_remove_at_Iter
https://bugs.kde.org/show_bug.cgi?id=369468
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=369456
Philippe Waroquiers changed:
What|Removed |Added
CC||rhysk...@gmail.com
--- Comment #5 from Ph
https://bugs.kde.org/show_bug.cgi?id=369456
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=361615
Philippe Waroquiers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=361615
Philippe Waroquiers changed:
What|Removed |Added
Summary|Inconsistent termination|Inconsistent termination
https://bugs.kde.org/show_bug.cgi?id=367995
--- Comment #19 from Philippe Waroquiers ---
(In reply to Ivo Raisr from comment #17)
> I will take care of the integration if Philippe is ok with it.
As indicated in comment 18, I think we can avoid relatively
easily the quadratic aspect.
Otherwise, if
https://bugs.kde.org/show_bug.cgi?id=367995
--- Comment #18 from Philippe Waroquiers ---
(In reply to Ruurd Beerstra from comment #15)
Thanks for all your work on this, I think this is useful
(I have not yet looked in depth, but I think this might be used
for the 'self-hosting' of valgrind, as v
https://bugs.kde.org/show_bug.cgi?id=367995
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=366035
--- Comment #13 from Philippe Waroquiers ---
(In reply to Julian Seward from comment #12)
> Philippe, is there anything we can or should do here?
The current hypothesis is that an ioctl used by alsa or a sound library is
not properly handled by syswrap
https://bugs.kde.org/show_bug.cgi?id=361615
--- Comment #8 from Philippe Waroquiers ---
(In reply to earl_chew from comment #4)
> Created attachment 100145 [details]
> Self contained test case
It seems there was an attachment problem.
Could you re-attach the self contained test case ?
Thanks
--
https://bugs.kde.org/show_bug.cgi?id=361615
--- Comment #7 from Philippe Waroquiers ---
(In reply to Julian Seward from comment #6)
> Philippe, didn't you fix something like this recently?
Not recently.
Related to thread termination, I did something some years ago, to fix bug
324227.
I can take a
https://bugs.kde.org/show_bug.cgi?id=368416
--- Comment #4 from Philippe Waroquiers ---
(In reply to Will Schmidt from comment #3)
> Created attachment 101061 [details]
> updated and refactored patch
>
> Per feedback and commentary, this is a different approach to solving the
> problem...
>
> U
https://bugs.kde.org/show_bug.cgi?id=368412
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=368416
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=368461
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=199468
Philippe Waroquiers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=199468
Philippe Waroquiers changed:
What|Removed |Added
Summary|Suppressions: stack size|Suppressions: stack size
https://bugs.kde.org/show_bug.cgi?id=199468
--- Comment #5 from Philippe Waroquiers ---
(In reply to Robin Kuzmin from comment #4)
> I have run through this discussion more thoroughly. My understanding how
> valgrind works (or should work) has changed. Here is my vision.
>
> In order to avoid mu
https://bugs.kde.org/show_bug.cgi?id=199468
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=366035
--- Comment #9 from Philippe Waroquiers ---
> I hope it helps too! What do you want me to do now? Is there some
> other tracing facility which I should run to help you identify the
> problematic ioctl? Do you want me to make the example program more
>
https://bugs.kde.org/show_bug.cgi?id=366035
--- Comment #7 from Philippe Waroquiers ---
(In reply to Frederick Eaton from comment #6)
> Hi Philippe,
>
> Thanks for responding.
>
> I'm using Arch Linux, it's weird that the default Arch package is not
> to your liking.
The assumption is that val
https://bugs.kde.org/show_bug.cgi?id=366035
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=360557
--- Comment #3 from Philippe Waroquiers ---
(In reply to Ari Sundholm from comment #2)
> This is not the case, as, per standard semantics for condition variables,
> pthread_cond_wait re-acquires the mutex before returning to the caller.
Yes, you are cor
https://bugs.kde.org/show_bug.cgi?id=365273
Philippe Waroquiers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=365273
--- Comment #7 from Philippe Waroquiers ---
Humph, I mean:
Just to be sure to be complete, please also add --trace-syscalls=yes
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=365273
--- Comment #6 from Philippe Waroquiers ---
Just to be sure to be complete, please also add --trace-signals=yes
Thanks
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=365273
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=365208
--- Comment #5 from Philippe Waroquiers ---
NB/ when adding additional trace, still keep the -v -v -v -d -d -d
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=365208
--- Comment #4 from Philippe Waroquiers ---
Effectively, there is not a lot more info.
It looks however that (some) user level code is being executed, as the user
stack
is being extended.
So, you might try to attach to the valgrind gdb server by doing
https://bugs.kde.org/show_bug.cgi?id=360557
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=365208
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=364058
Philippe Waroquiers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=364058
Philippe Waroquiers changed:
What|Removed |Added
Summary|array overruns are not |clarify in manual
|dete
https://bugs.kde.org/show_bug.cgi?id=364497
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=364058
--- Comment #6 from Philippe Waroquiers ---
(In reply to Sergey Meirovich from comment #5)
> Sorry. I indeed missed that. But why next also doesn't trigger any error
> message?
>
> -bash-4.1$ cat t.c
> int main(int c, char **o)
> {
> int stack[2];
https://bugs.kde.org/show_bug.cgi?id=364058
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=360008
--- Comment #9 from Philippe Waroquiers ---
Re-reading the comment at the beginning of valgrind-low-ppc64.c, the register
maps is
still not clear to me.
The comment tells there are 64 VSR registers of 64 bits.
But afterwards; the same commen tells that
https://bugs.kde.org/show_bug.cgi?id=362009
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=360008
--- Comment #5 from Philippe Waroquiers ---
I (quickly) read the patch (did not test), a few minor comments/questions:
* typo in power64-core.xml : typo: regect -> reject
* powerpc-altivec64l-valgrind.xml : I am not sure to fully understand why we
have
https://bugs.kde.org/show_bug.cgi?id=360008
--- Comment #3 from Philippe Waroquiers ---
Some more info:
* As discussed in comment 2, the vs registers high parts should be described.
It is however not clear to me if these registers should always be reported
to GDB
or if they should be report
https://bugs.kde.org/show_bug.cgi?id=360008
--- Comment #2 from Philippe Waroquiers ---
Sorry, I saw this bug but forgot to work on it, thanks for the reminder.
Here is what I think is wrong:
valgrind on ppc64 implements a ppc64 version that provides the registers vs0 ..
vs63.
The 'old' vr0 .. v
https://bugs.kde.org/show_bug.cgi?id=359705
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=349128
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=359133
--- Comment #10 from Philippe Waroquiers ---
(In reply to David Hallas from comment #9)
> So, should I go ahead and close the bug now that a testcase has been added?
Status was changed to RESOLVED/FIXED which seems to be the final status of
valgrind bu
https://bugs.kde.org/show_bug.cgi?id=359133
--- Comment #8 from Philippe Waroquiers ---
(In reply to David Hallas from comment #7)
> I have attached a reduced test case that shows the problem. I have tested
> with gcc-4.9.3 and clang-3.7.1 using a 64bit Linux PC. I compiled it like
> this:
>
> g
https://bugs.kde.org/show_bug.cgi?id=359133
--- Comment #5 from Philippe Waroquiers ---
(In reply to David Hallas from comment #4)
> I can try :) What would the format of a testcase be? Would a C++ code
> snippet be good enough?
A small compilable testcase c++ is ok.
Bonus points if the testcase
https://bugs.kde.org/show_bug.cgi?id=359133
Philippe Waroquiers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=359133
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=348345
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=303877
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=356457
--- Comment #15 from Philippe Waroquiers ---
(In reply to Joost VandeVondele from comment #14)
> Also no luck with --sanity-level=4
>
> The fact that it is not reproducible on command is indeed not simplifying
> this. I wonder if this could be related
https://bugs.kde.org/show_bug.cgi?id=356457
--- Comment #13 from Philippe Waroquiers ---
(In reply to Joost VandeVondele from comment #12)
Thanks for this data.
The warning about the stack switch is normal : valgrind has an heuristic to
detect stack switch. If a program uses huge stackframes, th
https://bugs.kde.org/show_bug.cgi?id=357871
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=358030
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=357037
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=357294
Philippe Waroquiers changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=353660
Philippe Waroquiers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=357034
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=357033
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=356457
--- Comment #9 from Philippe Waroquiers ---
(In reply to Joost VandeVondele from comment #8)
> I'll try something similar on the other machine, but the failure is not so
> easy to trigger, seemingly.
...
> There are many more static libraries involved,
https://bugs.kde.org/show_bug.cgi?id=356457
--- Comment #6 from Philippe Waroquiers ---
(In reply to Kim Rosberg from comment #4)
> I'm experience exactly the same behavior. But the interval is between +-4
> days and I'm running multiple servers 24h.
>
> ==247219== Memcheck, a memory error dete
https://bugs.kde.org/show_bug.cgi?id=356457
--- Comment #5 from Philippe Waroquiers ---
(In reply to Joost VandeVondele from comment #3)
> just happened again, but it is really rare. (this is a 12 core server
> running valgrind +-12h a day... and this seems to happen every +- 10 days).
> Is any o
https://bugs.kde.org/show_bug.cgi?id=191069
Philippe Waroquiers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=356273
--- Comment #5 from Philippe Waroquiers ---
(In reply to Ivo Raisr from comment #2)
> I tried the patch and I see quite a lot of merged entries on Solaris 12:
Yes, for sure, I also see a lot of 'addLoc merging' (which are done during
addLoc merging).
(N
https://bugs.kde.org/show_bug.cgi?id=356457
--- Comment #2 from Philippe Waroquiers ---
(In reply to Philippe Waroquiers from comment #1)
> in Valgrind, the 2nd action is most likely to find the problem.
The 3rd action (self-hosting) is in fact most likely to detect the buffer
overrun.
--
You
https://bugs.kde.org/show_bug.cgi?id=356457
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=356273
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=356174
--- Comment #17 from Philippe Waroquiers ---
Also, without a reasonable working equivalent of gdb 'monitor' command, a lot
of Valgrind gdbserver features are not usable.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=356174
--- Comment #16 from Philippe Waroquiers ---
(In reply to Daniel Trebbien from comment #15)
> Looking through the sources of the release_35 and release_36 branches, I see
> that LLDB 3.5 and 3.6 do not support the target.xml or target definition
> file
https://bugs.kde.org/show_bug.cgi?id=356174
--- Comment #13 from Philippe Waroquiers ---
(In reply to Daniel Trebbien from comment #10)
> (In reply to Philippe Waroquiers from comment #9)
> > Otherwise, valgrind gdbserver expects that the debugger knows the register
> > layout of x86 or amd64.
>
https://bugs.kde.org/show_bug.cgi?id=356174
--- Comment #9 from Philippe Waroquiers ---
An additional note: on x86 linux, valgrind gdbserver only reports the
Xfer:features:read+
supported if --vgdb-shadow-registers=yes is given.
On amd64 linux, Xfer:features:read+ is reported as supported if ei
https://bugs.kde.org/show_bug.cgi?id=356174
--- Comment #8 from Philippe Waroquiers ---
I already committed (svn 15743) the support for qC (slightly modified patch).
With this, lldb somewhat works on debian8/x86 or Ubuntu14/amd64
(e.g. continue till a breakpoint works).
However, in both environ
https://bugs.kde.org/show_bug.cgi?id=356174
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
https://bugs.kde.org/show_bug.cgi?id=356044
--- Comment #7 from Philippe Waroquiers ---
(In reply to Ivo Raisr from comment #6)
> Created attachment 95828 [details]
> proposed patch
>
> Adjacent DiLoc entries are now merged if they refer to the same line. This
> should give an improvement in ter
78 matches
Mail list logo
