[valgrind] [Bug 363680] add renameat2() support

https://bugs.kde.org/show_bug.cgi?id=363680 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0

[valgrind] [Bug 363714] ppc64 missing syscalls sync, waitid and name_to/open_by_handle_at

https://bugs.kde.org/show_bug.cgi?id=363714 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED

[valgrind] [Bug 363714] New: ppc64 missing syscalls sync, waitid and name_to/open_by_handle_at

https://bugs.kde.org/show_bug.cgi?id=363714 Bug ID: 363714 Summary: ppc64 missing syscalls sync, waitid and name_to/open_by_handle_at Product: valgrind Version: unspecified Platform: Other URL:

[valgrind] [Bug 363497] Crash if i run valgrind on any working program -> valgrind: the 'impossible' happened: LibVEX called failure_exit()

https://bugs.kde.org/show_bug.cgi?id=363497 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 356393] valgrind (vex) crashes because isZeroU happened

https://bugs.kde.org/show_bug.cgi?id=356393 Mark Wielaard changed: What|Removed |Added CC||gabriel.monta...@epfl.ch ---

[valgrind] [Bug 363705] arm64 missing syscall name_to_handle_at and open_by_handle_at

https://bugs.kde.org/show_bug.cgi?id=363705 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED

[valgrind] [Bug 363705] New: arm64 missing syscall name_to_handle_at and open_by_handle_at

https://bugs.kde.org/show_bug.cgi?id=363705 Bug ID: 363705 Summary: arm64 missing syscall name_to_handle_at and open_by_handle_at Product: valgrind Version: 3.11 SVN Platform: Other URL:

[valgrind] [Bug 361810] valgrind duplicate stdin after fork

https://bugs.kde.org/show_bug.cgi?id=361810 --- Comment #12 from Mark Wielaard --- Maybe --child-silent-after-fork=yes should imply run-libc-freeres=no for the fork? As I understand correctly the output sink is set to -1 for the fork already, so there cannot be any output.

[valgrind] [Bug 361810] valgrind duplicate stdin after fork

https://bugs.kde.org/show_bug.cgi?id=361810 Mark Wielaard changed: What|Removed |Added CC||m...@redhat.com --- Comment

[valgrind] [Bug 345307] Warning about "still reachable" memory when using libstdc++ from gcc 5

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

[valgrind] [Bug 361354] ppc64[le]: wire up separate socketcalls system calls

https://bugs.kde.org/show_bug.cgi?id=361354 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 361354] New: ppc64[le]: wire up separate socketcalls system calls

https://bugs.kde.org/show_bug.cgi?id=361354 Bug ID: 361354 Summary: ppc64[le]: wire up separate socketcalls system calls Product: valgrind Version: 3.11 SVN Platform: Other OS: Linux Status: UNCONFIRMED

[valgrind] [Bug 345307] Warning about "still reachable" memory when using libstdc++ from gcc 5

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

[valgrind] [Bug 345307] Warning about "still reachable" memory when using libstdc++ from gcc 5

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

[valgrind] [Bug 360425] arm64 unsupported instruction ldpsw

https://bugs.kde.org/show_bug.cgi?id=360425 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED

[valgrind] [Bug 360519] none/tests/arm64/memory.vgtest might fail with newer gcc

https://bugs.kde.org/show_bug.cgi?id=360519 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 360425] arm64 unsupported instruction ldpsw

https://bugs.kde.org/show_bug.cgi?id=360425 --- Comment #4 from Mark Wielaard --- (In reply to Peter Maydell from comment #3) > (In reply to Mark Wielaard from comment #1) > > I couldn't find a precise arm64 instruction encoding table > > This is all documented in the ARMv8

[valgrind] [Bug 360425] arm64 unsupported instruction ldpsw

https://bugs.kde.org/show_bug.cgi?id=360425 --- Comment #2 from Mark Wielaard --- Created attachment 97897 --> https://bugs.kde.org/attachment.cgi?id=97897=edit tests for ldpsw This groups the ldpsw tests with the ldp tests. Which causes some extra changes in later tests.

[valgrind] [Bug 360425] arm64 unsupported instruction ldpsw

https://bugs.kde.org/show_bug.cgi?id=360425 --- Comment #1 from Mark Wielaard --- Created attachment 97896 --> https://bugs.kde.org/attachment.cgi?id=97896=edit VEX implementation of ldpsw I couldn't find a precise arm64 instruction encoding table, so needed some

[valgrind] [Bug 360519] none/tests/arm64/memory.vgtest might fail with newer gcc

https://bugs.kde.org/show_bug.cgi?id=360519 --- Comment #1 from Mark Wielaard --- Created attachment 97892 --> https://bugs.kde.org/attachment.cgi?id=97892=edit Place nops around ldr literal test instruction and adjust expected output -- You are receiving this mail because:

[valgrind] [Bug 360519] New: none/tests/arm64/memory.vgtest might fail with newer gcc

https://bugs.kde.org/show_bug.cgi?id=360519 Bug ID: 360519 Summary: none/tests/arm64/memory.vgtest might fail with newer gcc Product: valgrind Version: 3.11 SVN Platform: Other OS: Linux Status:

[valgrind] [Bug 360425] New: arm64 unsupported instruction ldpsw

https://bugs.kde.org/show_bug.cgi?id=360425 Bug ID: 360425 Summary: arm64 unsupported instruction ldpsw Product: valgrind Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity:

[valgrind] [Bug 345307] Warning about "still reachable" memory when using libstdc++ from gcc 5

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

[valgrind] [Bug 359503] Add missing syscalls for aarch64 (arm64)

https://bugs.kde.org/show_bug.cgi?id=359503 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 359503] Add missing syscalls for aarch64 (arm64)

https://bugs.kde.org/show_bug.cgi?id=359503 --- Comment #9 from Mark Wielaard --- Created attachment 97794 --> https://bugs.kde.org/attachment.cgi?id=97794=edit Add more missing syscalls This adds most of the missing syscalls from the original patch for which I could do a

[valgrind] [Bug 359503] Add missing syscalls for aarch64 (arm64)

https://bugs.kde.org/show_bug.cgi?id=359503 --- Comment #8 from Mark Wielaard --- Created attachment 97787 --> https://bugs.kde.org/attachment.cgi?id=97787=edit Add arm64 scalar test. Enable tested syscalls. This adds a new memcheck/tests/arm64-linux/scalar test which is

[valgrind] [Bug 359503] Add missing syscalls for aarch64 (arm64)

https://bugs.kde.org/show_bug.cgi?id=359503 Mark Wielaard changed: What|Removed |Added Attachment #97762|0 |1 is obsolete|

[valgrind] [Bug 359503] Add missing syscalls for aarch64 (arm64)

https://bugs.kde.org/show_bug.cgi?id=359503 Mark Wielaard changed: What|Removed |Added CC||m...@redhat.com --- Comment

[valgrind] [Bug 345307] Warning about "still reachable" memory when using libstdc++ from gcc 5

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

[valgrind] [Bug 345307] Warning about "still reachable" memory when using libstdc++ from gcc 5

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

[valgrind] [Bug 345307] Warning about "still reachable" memory when using libstdc++ from gcc 5

https://bugs.kde.org/show_bug.cgi?id=345307 Mark Wielaard changed: What|Removed |Added CC||m...@redhat.com -- You are

[valgrind] [Bug 359733] amd64 implement strchr/index override to avoid need for suppression and redirection like x86

https://bugs.kde.org/show_bug.cgi?id=359733 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED

[valgrind] [Bug 359733] New: amd64 implement strchr/index override to avoid need for suppression and redirection like x86

https://bugs.kde.org/show_bug.cgi?id=359733 Bug ID: 359733 Summary: amd64 implement strchr/index override to avoid need for suppression and redirection like x86 Product: valgrind Version: unspecified Platform: Other

[valgrind] [Bug 359724] getsockname syscall might crash - deref_UInt should check make sure it is safe to deref

https://bugs.kde.org/show_bug.cgi?id=359724 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 359724] New: getsockname syscall might crash - deref_UInt should check make sure it is safe to deref

https://bugs.kde.org/show_bug.cgi?id=359724 Bug ID: 359724 Summary: getsockname syscall might crash - deref_UInt should check make sure it is safe to deref Product: valgrind Version: unspecified Platform: Other

[valgrind] [Bug 359703] s390: wire up separate socketcalls system calls

https://bugs.kde.org/show_bug.cgi?id=359703 --- Comment #1 from Mark Wielaard --- Created attachment 97376 --> https://bugs.kde.org/attachment.cgi?id=97376=edit S390 Split Socketcall Proposed patch. Simply wires up the split out system calls directly to the existing syswrap

[valgrind] [Bug 359703] New: s390: wire up separate socketcalls system calls

https://bugs.kde.org/show_bug.cgi?id=359703 Bug ID: 359703 Summary: s390: wire up separate socketcalls system calls Product: valgrind Version: 3.11 SVN Platform: Other OS: Linux Status: UNCONFIRMED

[valgrind] [Bug 359201] futex syscall "skips" argument 5 if op is FUTEX_WAIT_BITSET

https://bugs.kde.org/show_bug.cgi?id=359201 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED

[valgrind] [Bug 359201] futex syscall "skips" argument 5 if op is FUTEX_WAIT_BITSET

https://bugs.kde.org/show_bug.cgi?id=359201 Mark Wielaard changed: What|Removed |Added Resolution|FIXED |---

[valgrind] [Bug 359201] futex syscall "skips" argument 5 if op is FUTEX_WAIT_BITSET

https://bugs.kde.org/show_bug.cgi?id=359201 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED

[valgrind] [Bug 359289] s390x: popcnt (B9E1) not implemented

https://bugs.kde.org/show_bug.cgi?id=359289 --- Comment #2 from Mark Wielaard --- Thanks. Works for me on both the original program (libgccjit) and the simple reproducer. BTW. I believe the patch is missing an update to none/tests/s390x/Makefile.am to make sure the new test is

[valgrind] [Bug 359289] New: s390x: popcnt (B9E1) not implemented

https://bugs.kde.org/show_bug.cgi?id=359289 Bug ID: 359289 Summary: s390x: popcnt (B9E1) not implemented Product: valgrind Version: unspecified Platform: Other URL: https://bugzilla.redhat.com/show_bug.cgi?id=1306844

[valgrind] [Bug 359201] New: futex syscall "skips" argument 5 if op is FUTEXT_WAIT_BITSET

https://bugs.kde.org/show_bug.cgi?id=359201 Bug ID: 359201 Summary: futex syscall "skips" argument 5 if op is FUTEXT_WAIT_BITSET Product: valgrind Version: 3.11 SVN Platform: Other URL:

[valgrind] [Bug 358478] drd/tests/std_thread.cpp doesn't build with GCC6

https://bugs.kde.org/show_bug.cgi?id=358478 --- Comment #4 from Mark Wielaard --- (In reply to Bart Van Assche from comment #2) > Are gcc 6 RPMs available somewhere ? I am afraid not yet. I am using a hand build GCC6 for now. But Fedora rawhide is supposed to do a mass-rebuild

[valgrind] [Bug 358478] New: drd/tests/std_thread.cpp doesn't build with GCC6

https://bugs.kde.org/show_bug.cgi?id=358478 Bug ID: 358478 Summary: drd/tests/std_thread.cpp doesn't build with GCC6 Product: valgrind Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED

[valgrind] [Bug 358478] drd/tests/std_thread.cpp doesn't build with GCC6

https://bugs.kde.org/show_bug.cgi?id=358478 --- Comment #1 from Mark Wielaard --- Some for drd/tests/std_thread2.cpp which uses the same "trick". -- You are receiving this mail because: You are watching all bug changes.

[valgrind] [Bug 358213] helgrind/drd bar_bad testcase hangs with new glibc pthread barrier implementation

https://bugs.kde.org/show_bug.cgi?id=358213 Mark Wielaard changed: What|Removed |Added Attachment #96738|0 |1 is obsolete|

[valgrind] [Bug 358213] helgrind/drd bar_bad testcase hangs with new glibc pthread barrier implementation

https://bugs.kde.org/show_bug.cgi?id=358213 Mark Wielaard changed: What|Removed |Added Summary|helgrind bar_bad testcase |helgrind/drd bar_bad

[valgrind] [Bug 357833] Valgrind is broken on recent linux kernel

https://bugs.kde.org/show_bug.cgi?id=357833 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 358213] helgrind/drd bar_bad testcase hangs with new glibc pthread barrier implementation

https://bugs.kde.org/show_bug.cgi?id=358213 --- Comment #5 from Mark Wielaard --- Note that patch is missing the drd/test/Makefile.am addition of the two extra exp file: diff --git a/drd/tests/Makefile.am b/drd/tests/Makefile.am index 2885391..cfd74d0 100644 ---

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

https://bugs.kde.org/show_bug.cgi?id=358030 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[valgrind] [Bug 357833] Valgrind is broken on recent linux kernel

https://bugs.kde.org/show_bug.cgi?id=357833 Mark Wielaard changed: What|Removed |Added CC||m...@redhat.com --- Comment

[valgrind] [Bug 357833] Valgrind is broken on recent linux kernel

https://bugs.kde.org/show_bug.cgi?id=357833 --- Comment #4 from Mark Wielaard --- Replicated it now with the fedora rawhide kernel 4.5.0-0.rc0.git6.1.fc24.i686+PAE Not setting the RLIMIT_DATA to zero in coregrind/m_main.c (valgrind_main) does indeed work around it. -- You are

[valgrind] [Bug 358213] helgrind bar_bad testcase hangs with new glibc pthread barrier implementation

https://bugs.kde.org/show_bug.cgi?id=358213 --- Comment #2 from Mark Wielaard --- The patch to the testscase only works for helgrind, but the test program is also used under drd. It needs some different changes or you will get two failures: drd/tests/bar_bad

[valgrind] [Bug 357833] Valgrind is broken on recent linux kernel

https://bugs.kde.org/show_bug.cgi?id=357833 --- Comment #6 from Mark Wielaard --- Created attachment 96751 --> https://bugs.kde.org/attachment.cgi?id=96751=edit Remove setting zero RLIMIT_DATA The simplest seems to be to just remove the zero data rlimit. It also gets rid of

[valgrind] [Bug 357833] Valgrind is broken on recent linux kernel

https://bugs.kde.org/show_bug.cgi?id=357833 --- Comment #5 from Mark Wielaard --- For reference here is the full commit explaining that previously the RLIMIT_DATA value indeed was mostly harmless only affecting brk, but now restricts any data area allocations: commit

[valgrind] [Bug 358213] helgrind bar_bad testcase hangs with new glibc pthread barrier implementation

https://bugs.kde.org/show_bug.cgi?id=358213 --- Comment #1 from Mark Wielaard --- Created attachment 96738 --> https://bugs.kde.org/attachment.cgi?id=96738=edit pthread_barrier-vs-newer-glibc-implementation These changes make the bar_bad testcase PASS against both the old and

[valgrind] [Bug 357873] libstdc++ unhandled instruction: 0xF 0xC7 0xF0 0x89

https://bugs.kde.org/show_bug.cgi?id=357873 Mark Wielaard changed: What|Removed |Added Resolution|--- |DUPLICATE

[valgrind] [Bug 353370] RDRAND amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0 0x72 0x4 0xFF 0xC9

https://bugs.kde.org/show_bug.cgi?id=353370 Mark Wielaard changed: What|Removed |Added CC||miabr...@gmail.com ---

[valgrind] [Bug 323431] Unhandled AMD XOP instruction vpcmov VEX: unhandled instruction bytevex amd64->IR: 0x8F 0xE8 0x78 0xA2 0xC1 0x40 0xC5 0xFB

https://bugs.kde.org/show_bug.cgi?id=323431 Mark Wielaard changed: What|Removed |Added Summary|VEX: unhandled instruction |Unhandled AMD XOP

<    1   2