[valgrind] [Bug 356457] valgrind: m_mallocfree.c:2042 (vgPlain_arena_free): Assertion 'blockSane(a, b)' failed.

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

[valgrind] [Bug 356457] valgrind: m_mallocfree.c:2042 (vgPlain_arena_free): Assertion 'blockSane(a, b)' failed.

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

[valgrind] [Bug 369468] Implement HT_remove_at_Iter to avoid quadratic auto free pool algorithm

https://bugs.kde.org/show_bug.cgi?id=369468 Philippe Waroquiers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 369468] Implement HT_remove_at_Iter to avoid quadratic auto free pool algorithm

https://bugs.kde.org/show_bug.cgi?id=369468 Philippe Waroquiers changed: What|Removed |Added Summary|Implement |Implement

[valgrind] [Bug 369468] Implement HT_remove_at_Iter, allows removing the current entry from a table during iteration

https://bugs.kde.org/show_bug.cgi?id=369468 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 369456] callgrind_control failed to find an active callgrind run.

https://bugs.kde.org/show_bug.cgi?id=369456 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 369456] callgrind_control failed to find an active callgrind run.

https://bugs.kde.org/show_bug.cgi?id=369456 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 361615] Inconsistent termination for multithreaded process terminated by signal

https://bugs.kde.org/show_bug.cgi?id=361615 Philippe Waroquiers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 361615] Inconsistent termination for multithreaded process terminated by signal

https://bugs.kde.org/show_bug.cgi?id=361615 Philippe Waroquiers changed: What|Removed |Added Summary|Inconsistent termination

[valgrind] [Bug 367995] Integration of memcheck with custom memory allocator

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

[valgrind] [Bug 367995] Integration of memcheck with custom memory allocator

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

[valgrind] [Bug 367995] Integration of memcheck with custom memory allocator

https://bugs.kde.org/show_bug.cgi?id=367995 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime

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

[valgrind] [Bug 361615] Inconsistent termination when an instrumented multithreaded process is terminated by signal

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

[valgrind] [Bug 361615] Inconsistent termination when an instrumented multithreaded process is terminated by signal

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,

[valgrind] [Bug 368416] Add tc06_two_races_xml.exp output for ppc64.

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

[valgrind] [Bug 368412] False positive result for altivec capability check

https://bugs.kde.org/show_bug.cgi?id=368412 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 368416] Add tc06_two_races_xml.exp output for ppc64.

https://bugs.kde.org/show_bug.cgi?id=368416 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 368461] mmapunmap test fails on ppc64

https://bugs.kde.org/show_bug.cgi?id=368461 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 199468] Suppressions: stack size limited to 25 while --num-callers allows more frames

https://bugs.kde.org/show_bug.cgi?id=199468 Philippe Waroquiers changed: What|Removed |Added Resolution|--- |FIXED

[valgrind] [Bug 199468] Suppressions: stack size limited to 25 while --num-callers allows more frames

https://bugs.kde.org/show_bug.cgi?id=199468 Philippe Waroquiers changed: What|Removed |Added Summary|Suppressions: stack size

[valgrind] [Bug 199468] Suppressions: stack size limited to 25 while --num-callers allows up to 50 frames

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

[valgrind] [Bug 199468] Suppressions: stack size limited to 25 while --num-callers allows up to 50 frames

https://bugs.kde.org/show_bug.cgi?id=199468 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime

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

[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime

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

[valgrind] [Bug 366035] valgrind misses buffer overflow, segfaults in malloc in localtime

https://bugs.kde.org/show_bug.cgi?id=366035 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 360557] helgrind reports data race which I can't see (involves rwlocks)

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

[valgrind] [Bug 365273] Invalid write to stack location reported after signal handler runs

https://bugs.kde.org/show_bug.cgi?id=365273 Philippe Waroquiers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 365273] Invalid write to stack location reported after signal handler runs

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.

[valgrind] [Bug 365273] Invalid write to stack location reported after signal handler runs

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.

[valgrind] [Bug 365273] Invalid write to stack location reported after signal handler runs

https://bugs.kde.org/show_bug.cgi?id=365273 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 365208] valgrind stuck after redirecting "memcpy"

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.

[valgrind] [Bug 365208] valgrind stuck after redirecting "memcpy"

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

[valgrind] [Bug 360557] helgrind reports data race which I can't see (involves rwlocks)

https://bugs.kde.org/show_bug.cgi?id=360557 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 365208] valgrind stuck after redirecting "memcpy"

https://bugs.kde.org/show_bug.cgi?id=365208 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 364058] clarify in manual limitations of array overruns detections

https://bugs.kde.org/show_bug.cgi?id=364058 Philippe Waroquiers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 364058] clarify in manual limitations of array overruns detections

https://bugs.kde.org/show_bug.cgi?id=364058 Philippe Waroquiers changed: What|Removed |Added Summary|array overruns are not |clarify in

[valgrind] [Bug 364497] Run valgrind on nginx

https://bugs.kde.org/show_bug.cgi?id=364497 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 364058] array overruns are not detected

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,

[valgrind] [Bug 364058] array overruns are not detected

https://bugs.kde.org/show_bug.cgi?id=364058 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 362009] Valgrind dumps core on unimplemented functionality before threads are created

https://bugs.kde.org/show_bug.cgi?id=362009 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 360008] Contents of Power vr registers contents is not printed correctly when the --vgdb-shadow-registers=yes option is used.

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

[valgrind] [Bug 360008] Contents of Power vr registers contents is not printed correctly when the --vgdb-shadow-registers=yes option is used.

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

[valgrind] [Bug 360008] Contents of Power vr registers contents is not printed correctly when the --vgdb-shadow-registers=yes option is used.

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

[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686

https://bugs.kde.org/show_bug.cgi?id=359705 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 349128] Access not within mapped region in _pthread_find_thread (OS X 10.11)

https://bugs.kde.org/show_bug.cgi?id=349128 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 359133] m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion 'eltSzB <= ddpa->poolSzB' failed.

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

[valgrind] [Bug 359133] m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion 'eltSzB <= ddpa->poolSzB' failed.

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

[valgrind] [Bug 359133] m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion 'eltSzB <= ddpa->poolSzB' failed.

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

[valgrind] [Bug 359133] m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion 'eltSzB <= ddpa->poolSzB' failed.

https://bugs.kde.org/show_bug.cgi?id=359133 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 359133] m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion 'eltSzB <= ddpa->poolSzB' failed.

https://bugs.kde.org/show_bug.cgi?id=359133 Philippe Waroquiers changed: What|Removed |Added Resolution|--- |FIXED

[valgrind] [Bug 348345] Assertion fails for negative lineno

https://bugs.kde.org/show_bug.cgi?id=348345 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 303877] valgrind doesn't support compressed debuginfo sections.

https://bugs.kde.org/show_bug.cgi?id=303877 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 356457] valgrind: m_mallocfree.c:2042 (vgPlain_arena_free): Assertion 'blockSane(a, b)' failed.

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

[valgrind] [Bug 356457] valgrind: m_mallocfree.c:2042 (vgPlain_arena_free): Assertion 'blockSane(a, b)' failed.

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

[valgrind] [Bug 357871] pthread_spin_destroy not properly wrapped

https://bugs.kde.org/show_bug.cgi?id=357871 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 358030] support direct socket calls on x86 32bit (new in linux 4.3)

https://bugs.kde.org/show_bug.cgi?id=358030 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 357294] cannot start valgrind with tool dhat

https://bugs.kde.org/show_bug.cgi?id=357294 Philippe Waroquiers changed: What|Removed |Added Resolution|--- |WONTFIX

[valgrind] [Bug 353660] XML in auxwhat tag not escaping reserved symbols properly

https://bugs.kde.org/show_bug.cgi?id=353660 Philippe Waroquiers changed: What|Removed |Added Resolution|--- |FIXED

[valgrind] [Bug 357033] VALGRIND_DO_QUICK_LEAK_CHECK reports leaked and dubious memory as reachable in intel-compiled applications.

https://bugs.kde.org/show_bug.cgi?id=357033 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 357034] Inlined functions are not reported for intel-compiled applications.

https://bugs.kde.org/show_bug.cgi?id=357034 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 356457] valgrind: m_mallocfree.c:2042 (vgPlain_arena_free): Assertion 'blockSane(a, b)' failed.

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

[valgrind] [Bug 356457] valgrind: m_mallocfree.c:2042 (vgPlain_arena_free): Assertion 'blockSane(a, b)' failed.

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

[valgrind] [Bug 191069] Exiting due to signal not reported in XML output

https://bugs.kde.org/show_bug.cgi?id=191069 Philippe Waroquiers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 356273] conserve memory by merging adjacent DiLoc entries in the debug info location table

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

[valgrind] [Bug 356457] valgrind: m_mallocfree.c:2042 (vgPlain_arena_free): Assertion 'blockSane(a, b)' failed.

https://bugs.kde.org/show_bug.cgi?id=356457 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 356273] conserve memory by merging adjacent DiLoc entries in the debug info location table

https://bugs.kde.org/show_bug.cgi?id=356273 Philippe Waroquiers changed: What|Removed |Added CC|

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

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

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

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,

[valgrind] [Bug 356044] Dwarf line info reader misinterprets is_stmt register

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 >

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

https://bugs.kde.org/show_bug.cgi?id=356174 Philippe Waroquiers changed: What|Removed |Added CC|