[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch
https://bugs.kde.org/show_bug.cgi?id=317127
--- Comment #21 from Mark Wielaard ---
Could we make it linux generic by just using __NR_statfs and struct statfs
(which seems defined for each linux arch already):
diff --git a/coregrind/m_aspacemgr/aspacemgr-linux.c
b/coregrind/m_aspacemgr/aspacemgr-linux.c
index 9362f65af3c8..3da68db381e1 100644
--- a/coregrind/m_aspacemgr/aspacemgr-linux.c
+++ b/coregrind/m_aspacemgr/aspacemgr-linux.c
@@ -891,6 +891,14 @@ static void sync_check_mapping_callback ( Addr addr, SizeT
len, UInt prot,
/* hack apparently needed on MontaVista Linux */
if (filename && VG_(strstr)(filename, "/.lib-ro/"))
cmp_devino = False;
+
+#if defined(VGO_linux)
+ struct vki_statfs statfs = {0};
+ SysRes res = VG_(do_syscall2)(__NR_statfs, (UWord)filename,
(UWord));
+ if (!sr_isError(res) && statfs.f_type == VKI_BTRFS_SUPER_MAGIC) {
+ cmp_devino = False;
+ }
+#endif
#endif
/* If we are doing sloppy execute permission checks then we
diff --git a/include/vki/vki-linux.h b/include/vki/vki-linux.h
index be3d76690cee..708a12b64d03 100644
--- a/include/vki/vki-linux.h
+++ b/include/vki/vki-linux.h
@@ -5455,6 +5460,12 @@ struct vki_open_how {
#define VKI_CLOSE_RANGE_UNSHARE (1U << 1)
#define VKI_CLOSE_RANGE_CLOEXEC (1U << 2)
+//--
+// From linux/magic.h
+//--
+
+#define VKI_BTRFS_SUPER_MAGIC0x9123683E
+
/**/
/*--- end ---*/
/**/
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 489676] vgdb handle EINTR and EAGAIN more consistently
https://bugs.kde.org/show_bug.cgi?id=489676 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Assignee|jsew...@acm.org |m...@klomp.org Status|REPORTED|CONFIRMED --- Comment #1 from Mark Wielaard --- Created attachment 171330 --> https://bugs.kde.org/attachment.cgi?id=171330=edit vgdb: Handle EINTR and EAGAIN more consistently vgdb: Handle EINTR and EAGAIN more consistently Always handle EINTR or EAGAIN when calling read or write. Also be consistent in the use of size_t and ssize_t for arguments and return values. This should make vgdb more robust against receiving signals or a blocked pipe at the wrong time. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489676] New: vgdb handle EINTR and EAGAIN more consistently
https://bugs.kde.org/show_bug.cgi?id=489676 Bug ID: 489676 Summary: vgdb handle EINTR and EAGAIN more consistently Classification: Developer tools Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: m...@klomp.org Target Milestone: --- vgdb doesn't handle EINTR and EAGAIN very consistently. Sometimes when a signal arrives at the wrong time vgdb just errors out instead of retrying to read or write a package. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch
https://bugs.kde.org/show_bug.cgi?id=317127 Mark Wielaard changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #20 from Mark Wielaard --- Patch works for me. It is a little unfortunate that vki_statfs is arch specific. uapi/asm-generic/statfs.h says: /* * Most 64-bit platforms use 'long', while most 32-bit platforms use '__u32'. * Yes, they differ in signedness as well as size. * Special cases can override it for themselves -- except for S390x, which * is just a little too special for us. And MIPS, which I'm not touching * with a 10' pole. */ But I think we can make it linux-generic even without updating vki_statfs everywhere. We don't seem to use the new f_flags anywhere. We just need to check f_type. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489221] Unrecognized instruction: _mm256_cvtps_ph (vcvtps2ph)
https://bugs.kde.org/show_bug.cgi?id=489221 --- Comment #5 from Mark Wielaard --- This was implemented in: commit 472b067e39a11a47ae3fa7cd7d3142558f78969d Author: Julian Seward Date: Sun Mar 17 21:41:42 2019 +0100 amd64: Implement RDRAND, VCVTPH2PS and VCVTPS2PH. Bug 398870 - Please add support for instruction vcvtps2ph Bug 353370 - RDRAND amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0 This commit implements: * amd64 RDRAND instruction, on hosts that have it. * amd64 VCVTPH2PS and VCVTPS2PH, on hosts that have it. The presence/absence of these on the host is now reflected in the CPUID results returned to the guest. So code that tests for these features in CPUID and acts accordingly should "just work". * New test cases, none/tests/amd64/rdrand and none/tests/amd64/f16c. These are built if the host's assembler can handle them, in the usual way. And on my machine the reproducer works just fine under valgrind. If it still doesn't for you with latest valgrind could you run with valgrind -v and check the hwcaps detect f16c: --411301-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed-fma (and check your machine does actually have f16c set in /proc/cpuinfo) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489088] Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5 0xFA 0x7E 0xDB 0xC5 0xF8
https://bugs.kde.org/show_bug.cgi?id=489088 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489088] Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5 0xFA 0x7E 0xDB 0xC5 0xF8
https://bugs.kde.org/show_bug.cgi?id=489088 --- Comment #12 from Mark Wielaard --- commit 10a22445d747817932692b1c1ee3faa726121cb4 Author: Mark Wielaard Date: Sun Jun 30 20:17:32 2024 +0200 Implement VMOVQ xmm1, xmm2/m64 We implemented the memory variant already, but not the reg variant. Add a separate avx-vmovq testcase, because avx-1 is already really big. https://bugs.kde.org/show_bug.cgi?id=391148 https://bugs.kde.org/show_bug.cgi?id=417572 https://bugs.kde.org/show_bug.cgi?id=489088 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417572] vex amd64->IR: unhandled instruction bytes: 0xC5 0x79 0xD6 0xED 0xC5 0xF9 0x51
https://bugs.kde.org/show_bug.cgi?id=417572 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Mark Wielaard --- commit 10a22445d747817932692b1c1ee3faa726121cb4 Author: Mark Wielaard Date: Sun Jun 30 20:17:32 2024 +0200 Implement VMOVQ xmm1, xmm2/m64 We implemented the memory variant already, but not the reg variant. Add a separate avx-vmovq testcase, because avx-1 is already really big. https://bugs.kde.org/show_bug.cgi?id=391148 https://bugs.kde.org/show_bug.cgi?id=417572 https://bugs.kde.org/show_bug.cgi?id=489088 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 391148] Unhandled AVX instruction vmovq %xmm9,%xmm1
https://bugs.kde.org/show_bug.cgi?id=391148 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED CC||m...@klomp.org --- Comment #5 from Mark Wielaard --- commit 10a22445d747817932692b1c1ee3faa726121cb4 Author: Mark Wielaard Date: Sun Jun 30 20:17:32 2024 +0200 Implement VMOVQ xmm1, xmm2/m64 We implemented the memory variant already, but not the reg variant. Add a separate avx-vmovq testcase, because avx-1 is already really big. https://bugs.kde.org/show_bug.cgi?id=391148 https://bugs.kde.org/show_bug.cgi?id=417572 https://bugs.kde.org/show_bug.cgi?id=489088 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489088] Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5 0xFA 0x7E 0xDB 0xC5 0xF8
https://bugs.kde.org/show_bug.cgi?id=489088 Mark Wielaard changed: What|Removed |Added Assignee|jsew...@acm.org |m...@klomp.org Status|CONFIRMED |ASSIGNED --- Comment #10 from Mark Wielaard --- Created attachment 171207 --> https://bugs.kde.org/attachment.cgi?id=171207=edit Implement VMOVQ xmm1, xmm2/m64 Added testcase, which showed we cleared the wrong register (oops). Fixed that in the implementation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489088] Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5 0xFA 0x7E 0xDB 0xC5 0xF8
https://bugs.kde.org/show_bug.cgi?id=489088
--- Comment #8 from Mark Wielaard ---
So I think the implementation should be something like:
diff --git a/VEX/priv/guest_amd64_toIR.c b/VEX/priv/guest_amd64_toIR.c
index 28c37f092211..a7ea5951aac7 100644
--- a/VEX/priv/guest_amd64_toIR.c
+++ b/VEX/priv/guest_amd64_toIR.c
@@ -27026,6 +27026,14 @@ Long dis_ESC_0F__VEX (
if (epartIsReg(modrm)) {
/* fall through, awaiting test case */
/* dst: lo half copied, hi half zeroed */
+UInt rE = eregOfRexRM(pfx,modrm);
+putXMMRegLane64( rE, 0, getXMMRegLane64( rG, 0 ));
+/* zero bits 255:64 */
+putXMMRegLane64( rG, 1, mkU64(0) );
+putYMMRegLane128( rG, 1, mkV128(0) );
+DIP("vmovq %s,%s\n", nameXMMReg(rG), nameXMMReg(rE));
+delta += 1;
+goto decode_success;
} else {
addr = disAMode ( , vbi, pfx, delta, dis_buf, 0 );
storeLE( mkexpr(addr), getXMMRegLane64( rG, 0 ));
But obviously we need some real test cases.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 489221] Unrecognized instruction: _mm256_cvtps_ph (vcvtps2ph)
https://bugs.kde.org/show_bug.cgi?id=489221 Mark Wielaard changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|DUPLICATE |--- --- Comment #4 from Mark Wielaard --- Sorry, looks like you are right. I was confused with the m512 variant, which is AVX512F. The m256 variant is part of F16C. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489221] Unrecognized instruction: _mm256_cvtps_ph (vcvtps2ph)
https://bugs.kde.org/show_bug.cgi?id=489221 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- The m256 variant is part of AVX512F -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489088] Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5 0xFA 0x7E 0xDB 0xC5 0xF8
https://bugs.kde.org/show_bug.cgi?id=489088
Mark Wielaard changed:
What|Removed |Added
Ever confirmed|0 |1
Status|REPORTED|CONFIRMED
--- Comment #6 from Mark Wielaard ---
(In reply to Sam James from comment #5)
> (In reply to Mark Wielaard from comment #4)
> > See also https://bugs.kde.org/show_bug.cgi?id=391148 which comes with a
> > patch.
>
> Hi Mark, thanks for looking!
>
> That patch seems to work:
>
> ```
> ==144687== Invalid read of size 8
> ==144687==at 0x109F43: filter (test.c:59)
> ==144687==by 0x109F43: AnalyzeSamples (test.c:100)
> ==144687==by 0x109366: main (test.c:167)
> ==144687== Address 0x4637bfeabfe4bbd4 is not stack'd, malloc'd or
> (recently) free'd
> ==144687==
> ==144687==
> ==144687== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==144687== General Protection Fault
> ==144687==at 0x109F43: filter (test.c:59)
> ==144687==by 0x109F43: AnalyzeSamples (test.c:100)
> ==144687==by 0x109366: main (test.c:167)
> ```
> although the address looks a bit suspicious and I wasn't aware of out of
> bounds access in the testcase, so not sure if it really is decoding fully
> correctly?
hmmm, yeah that is kind of odd. That address is so weird that it really must be
invalid. Does the original program also try to read from that address and
produce a SIGSEGV when not run under valgrind?
Maybe as a quick hack check you could change that DIP("vmovq %s,%s\n",
nameXMMReg(rG), nameIReg64(rE)); in the patch to vex_printf(...)
If it decodes correctly it should print vmovq %xmm12,%xmm0
(You can also get some of that with something like --trace-flags=1000
--trace-notbelow=1000 but that is really verbose)
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 417572] vex amd64->IR: unhandled instruction bytes: 0xC5 0x79 0xD6 0xED 0xC5 0xF9 0x51
https://bugs.kde.org/show_bug.cgi?id=417572 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=489088 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489088] Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5 0xFA 0x7E 0xDB 0xC5 0xF8
https://bugs.kde.org/show_bug.cgi?id=489088 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=417572 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 391148] Unhandled AVX instruction vmovq %xmm9,%xmm1
https://bugs.kde.org/show_bug.cgi?id=391148 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=489088 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489088] Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5 0xFA 0x7E 0xDB 0xC5 0xF8
https://bugs.kde.org/show_bug.cgi?id=489088 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=391148 --- Comment #4 from Mark Wielaard --- See also https://bugs.kde.org/show_bug.cgi?id=391148 which comes with a patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 489088] Valgrind throws unhandled instruction bytes: 0xC5 0x79 0xD6 0xE0 0xC5 0xFA 0x7E 0xDB 0xC5 0xF8
https://bugs.kde.org/show_bug.cgi?id=489088 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #3 from Mark Wielaard --- This looks like vmovq: 0x00109df7 <+>: vshufps $0x55,%xmm1,%xmm1,%xmm4 0x00109dfc <+1116>: vmovshdup %xmm0,%xmm1 => 0x00109e00 <+1120>: vmovq %xmm12,%xmm0 0x00109e04 <+1124>: vmovq %xmm3,%xmm3 0x00109e08 <+1128>: vmovaps %xmm2,-0x50(%rbp) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 487439] SIGILL in JDK11, JDK17
https://bugs.kde.org/show_bug.cgi?id=487439 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #19 from Mark Wielaard --- See commit in comment #18 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 337388] fcntl works on Valgrind's own file descriptors
https://bugs.kde.org/show_bug.cgi?id=337388 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #4 from Mark Wielaard --- (In reply to Alexandra Hajkova from comment #3) > Created attachment 170678 [details] > patch Thanks. Looks good. commit 4b83e3d47daaf5eff2ca96867a8c790e13830eb5 Author: Alexandra Hájková Date: Thu Jun 20 07:45:56 2024 -0400 Don't allow programs calling fnctl on valgrind's own file descriptors Add a call to ML_(fd_allowed) in the PRE handler of fcntl and fcntl64 and block syscalls with EBADF when the file descriptor isn't allowed to be used by the program. https://bugs.kde.org/show_bug.cgi?id=337388 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 331311] Valgrind shows open files in /proc/self/fd that don't work for the process
https://bugs.kde.org/show_bug.cgi?id=331311 --- Comment #4 from Mark Wielaard --- Note that the "test" program for bug https://bugs.kde.org/show_bug.cgi?id=337388 makes use of this bug. It would be nice if we could "virtualize" /proc/self/fd and /proc/self/fdinfo But up to now we have only "virtualized" proc files, not proc directories. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 337388] fcntl works on Valgrind's own file descriptors
https://bugs.kde.org/show_bug.cgi?id=337388
--- Comment #2 from Mark Wielaard ---
Note that there is a bug in the example program:
fds = calloc(size, sizeof fds[0]);
if (fds != NULL) {
errnum = errno;
goto close_fds_dir;
}
should be if (fds == NULL)
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 479661] Valgrind leaks file descriptors
https://bugs.kde.org/show_bug.cgi?id=479661 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Mark Wielaard --- commit 1263471efdf8405cb0f1a767c6af73bf2eaf7160 Author: Mark Wielaard Date: Mon Jun 17 00:27:12 2024 +0200 Close both internal pipe fds after VG_(fork) in parent and child An VG_fork() creates a pipe between parent and child to syncronize the two processes. The parent wants to register the child pid before the child can run. This is done in register_sigchld_ignore. Make sure both the parent and the child close both the read and write file descriptors so none leak. https://bugs.kde.org/show_bug.cgi?id=479661 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 488379] --track-fds=yes generates errors that cannot be suppressed for valgrind internal --xml-file=
https://bugs.kde.org/show_bug.cgi?id=488379 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #4 from Mark Wielaard --- commit fbd7596f8342f0b0fbbe088d960da839a8bdb839 Author: Mark Wielaard Date: Sun Jun 16 21:23:08 2024 +0200 Don't leave fds created with --log-file, --xml-file or --log-socket open prepare_sink_fd and prepare_sink_socket will create a new file descriptor for the output sink. finalize_sink_fd then copies the fd to the safe range, so it doesn't conflict with any application fds. If we created the original fd ourselves, it was a VgLogTo_File or VgLogTo_Socket, not VgLogTo_Fd, finalize_sink_fd should close it. Also close socket when connecting fails in VG_(connect_via_socket). Add a testcase for --log-file and --xml-file which prints output to /dev/stderr https://bugs.kde.org/show_bug.cgi?id=202770 https://bugs.kde.org/show_bug.cgi?id=311655 https://bugs.kde.org/show_bug.cgi?id=488379 Co-authored-by: Alexandra Hájková
[valgrind] [Bug 311655] --log-file=FILE leads to apparent fd leak ("Open file descriptor 3: $LOGFILE")
https://bugs.kde.org/show_bug.cgi?id=311655 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit fbd7596f8342f0b0fbbe088d960da839a8bdb839 Author: Mark Wielaard Date: Sun Jun 16 21:23:08 2024 +0200 Don't leave fds created with --log-file, --xml-file or --log-socket open prepare_sink_fd and prepare_sink_socket will create a new file descriptor for the output sink. finalize_sink_fd then copies the fd to the safe range, so it doesn't conflict with any application fds. If we created the original fd ourselves, it was a VgLogTo_File or VgLogTo_Socket, not VgLogTo_Fd, finalize_sink_fd should close it. Also close socket when connecting fails in VG_(connect_via_socket). Add a testcase for --log-file and --xml-file which prints output to /dev/stderr https://bugs.kde.org/show_bug.cgi?id=202770 https://bugs.kde.org/show_bug.cgi?id=311655 https://bugs.kde.org/show_bug.cgi?id=488379 Co-authored-by: Alexandra Hájková
[valgrind] [Bug 202770] open fd at exit --log-socket=127.0.0.1:1500 with --track-fds=yes and --trace-children=yes with a program that calls fork then exec
https://bugs.kde.org/show_bug.cgi?id=202770 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #6 from Mark Wielaard --- commit fbd7596f8342f0b0fbbe088d960da839a8bdb839 Author: Mark Wielaard Date: Sun Jun 16 21:23:08 2024 +0200 Don't leave fds created with --log-file, --xml-file or --log-socket open prepare_sink_fd and prepare_sink_socket will create a new file descriptor for the output sink. finalize_sink_fd then copies the fd to the safe range, so it doesn't conflict with any application fds. If we created the original fd ourselves, it was a VgLogTo_File or VgLogTo_Socket, not VgLogTo_Fd, finalize_sink_fd should close it. Also close socket when connecting fails in VG_(connect_via_socket). Add a testcase for --log-file and --xml-file which prints output to /dev/stderr https://bugs.kde.org/show_bug.cgi?id=202770 https://bugs.kde.org/show_bug.cgi?id=311655 https://bugs.kde.org/show_bug.cgi?id=488379 Co-authored-by: Alexandra Hájková
[valgrind] [Bug 479661] Valgrind leaks file descriptors
https://bugs.kde.org/show_bug.cgi?id=479661 --- Comment #4 from Mark Wielaard --- Created attachment 170562 --> https://bugs.kde.org/attachment.cgi?id=170562=edit Close both internal pipe fds after VG_(fork) in parent and child Close both internal pipe fds after VG_(fork) in parent and child An VG_fork() creates a pipe between parent and child to syncronize the two processes. The parent wants to register the child pid before the child can run. This is done in register_sigchld_ignore. Make sure both the parent and the child close both the read and write file descriptors so none leak. https://bugs.kde.org/show_bug.cgi?id=479661 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 488379] --track-fds=yes generates errors that cannot be suppressed for valgrind internal --xml-file=
https://bugs.kde.org/show_bug.cgi?id=488379 --- Comment #3 from Mark Wielaard --- Created attachment 170559 --> https://bugs.kde.org/attachment.cgi?id=170559=edit Don't leave fds created with --log-file, --xml-file or --log-socket open Don't leave fds created with --log-file, --xml-file or --log-socket open prepare_sink_fd and prepare_sink_socket will create a new file descriptor for the output sink. finalize_sink_fd then copies the fd to the safe range, so it doesn't conflict with any application fds. If we created the original fd ourselves, it was a VgLogTo_File or VgLogTo_Socket, not VgLogTo_Fd, finalize_sink_fd should close it. Also close socket when connecting fails in VG_(connect_via_socket). Add a testcase for --log-file and --xml-file which prints output to /dev/stderr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 488441] Add the tests for for --track-fds=yes --xml=yes and file descriptor suppression tests
https://bugs.kde.org/show_bug.cgi?id=488441 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED CC||m...@klomp.org --- Comment #3 from Mark Wielaard --- Thanks, it is good to see more tests for the file descriptor tracking, xml and suppression support. I swapped a few things around, so each commit stands on its own. And added some tweaks for older ppc64 rhel7 (with broken backtraces). commit 8864c92efb8f65d8a56153f3bc8f7d2ac907b6cb Author: Alexandra Hájková Date: Thu May 23 04:39:54 2024 -0400 Add file descriptor suppression tests - none/tests/double_close_range_sup.vgtest - none/tests/fdleak_cmsg_supp.vgtest - none/tests/fdleak_creat_sup.vgtest - none/tests/file_dclose_sup.vgtest https://bugs.kde.org/show_bug.cgi?id=488441 commit 6369c67d37c40c312f5403a08a23e5da878688db Author: Alexandra Hájková Date: Tue Apr 23 09:17:03 2024 -0400 Add the tests for --track-fds=yes --xml=yes - none/tests/double_close_range_xml.vgtest - none/tests/fdleak_cmsg_xml.vgtest - none/tests/fdleak_creat_xml.vgtest - none/tests/fdleak_dup_xml.vgtest - none/tests/fdleak_dup2_xml.vgtest - none/tests/fdleak_fcntl_xml.vgtest - none/tests/fdleak_ipv4_xml.vgtest - none/tests/fdleak_open_xml.vgtest - none/tests/fdleak_pipe_xml.vgtest - none/tests/fdleak_socketpair_xml.vgtest - none/tests/file_dclose_xml.vgtest - none/tests/socket_close_xml.vgtest Add a new filter_xml. Note the use of --child-silent-after-fork=yes usage in two vgtests. Maybe this should be the default for --xml=yes? Otherwise xml output will be "corrupted" by output from a fork. https://bugs.kde.org/show_bug.cgi?id=488441 commit 8b374fd2bce60a58809b4f95a93d7e2f01929a08 Author: Alexandra Hájková Date: Thu May 23 04:46:26 2024 -0400 Improve none/tests/double_close_range test and filter_fdleak Adjust none/tests/file_dclose, none/tests/fdleak_ipv4 and socket_close to fit the changes in filter_fdleak. https://bugs.kde.org/show_bug.cgi?id=488441 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 202770] open fd at exit --log-socket=127.0.0.1:1500 with --track-fds=yes and --trace-children=yes with a program that calls fork then exec
https://bugs.kde.org/show_bug.cgi?id=202770 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 See Also||https://bugs.kde.org/show_b ||ug.cgi?id=311655 Status|REPORTED|CONFIRMED --- Comment #5 from Mark Wielaard --- This seems a different variant of https://bugs.kde.org/show_bug.cgi?id=311655 but with --log-socket= instead of --log-file= See also bug 488379 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 202770] open fd at exit --log-socket=127.0.0.1:1500 with --track-fds=yes and --trace-children=yes with a program that calls fork then exec
https://bugs.kde.org/show_bug.cgi?id=202770 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=488379 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 488379] --track-fds=yes generates errors that cannot be suppressed for valgrind internal --xml-file=
https://bugs.kde.org/show_bug.cgi?id=488379 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=202770 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 311655] --log-file=FILE leads to apparent fd leak ("Open file descriptor 3: $LOGFILE")
https://bugs.kde.org/show_bug.cgi?id=311655 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=202770 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 479661] Valgrind leaks file descriptors
https://bugs.kde.org/show_bug.cgi?id=479661
--- Comment #3 from Mark Wielaard ---
I don't think it was the commit 0432ce ("vgdb: implement the extended-remote
protocol") which seems to use CLOSEXEC correctly.
It seems to be related to the pipe created for debuginfod support, commit
fd4e3f ("PR432215 Add debuginfod functionality") which uses a "plain" pipe
instead of a pipe2 with O_CLOEXEC flag.
The issue goes away when doing unset DEBUGINFOD_URLS.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 479661] Valgrind leaks file descriptors
https://bugs.kde.org/show_bug.cgi?id=479661 Mark Wielaard changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #2 from Mark Wielaard --- I see only one "leaked" file description for the echo command: ==1727176== FILE DESCRIPTORS: 2 open (1 std) at exit. ==1727176== Open file descriptor 9: ==1727176== But 3 (!?) when using -v: ==1727335== FILE DESCRIPTORS: 4 open (1 std) at exit. ==1727335== Open file descriptor 11: ==1727335== ==1727335== ==1727335== Open file descriptor 10: ==1727335== ==1727335== ==1727335== Open file descriptor 8: ==1727335== -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 488379] --track-fds=yes generates errors that cannot be suppressed for valgrind internal --xml-file=
https://bugs.kde.org/show_bug.cgi?id=488379 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=311655 --- Comment #2 from Mark Wielaard --- This is probably the same underlying issues as bug #311655 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 311655] --log-file=FILE leads to apparent fd leak ("Open file descriptor 3: $LOGFILE")
https://bugs.kde.org/show_bug.cgi?id=311655 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=488379 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 402833] memcheck/tests/overlap testcase fails, memcpy seen as memmove
https://bugs.kde.org/show_bug.cgi?id=402833
--- Comment #20 from Mark Wielaard ---
(In reply to Paul Floyd from comment #19)
> (In reply to Olly Betts from comment #18)
> > $ nm -D /usr/lib/x86_64-linux-gnu/libc.so.6|grep 00119f80
> > 00119f80 i __memcpy_chk@@GLIBC_2.3.4
> > $ nm -D /usr/lib/x86_64-linux-gnu/libc.so.6|grep 0011a090
> > 0011a090 i __memmove_chk@@GLIBC_2.3.4
>
> That's not what I was expecting. If the memmove was inlined and
> __memcpy_chk and __memmove_chk are aliases then Memcheck
> will only use one of them (__memcpy_chk from the errors you got).
Note that the "i" means ifunc. So they get resolved at runtime through an ifunc
call.
It depends on cpu features to which this ifunc resolves. So it could very well
be that
they resolve to the same address at runtime on one machine, but not on another.
> If that's the case then your problem was probably fixed by Mark in October
> 2023:
>
> 39c447e4a9 (Bart Van Assche 2013-11-24 17:48:13 + 1716)
> /* memcpy_chk */
> 39c447e4a9 (Bart Van Assche 2013-11-24 17:48:13 + 1717)
> 53e101f562 (Mark Wielaard 2023-10-30 23:30:06 +0100 1718) /* See
> https://bugs.kde.org/show_bug.cgi?id=402833
> 53e101f562 (Mark Wielaard 2023-10-30 23:30:06 +0100 1719)why we
> disable the overlap check on x86_64. */
> 53e101f562 (Mark Wielaard 2023-10-30 23:30:06 +0100 1720) #if
> defined(VGP_amd64_linux)
> 53e101f562 (Mark Wielaard 2023-10-30 23:30:06 +0100 1721) #define
> CHECK_OVERLAP 0
> 53e101f562 (Mark Wielaard 2023-10-30 23:30:06 +0100 1722) #else
> 53e101f562 (Mark Wielaard 2023-10-30 23:30:06 +0100 1723) #define
> CHECK_OVERLAP 1
> 53e101f562 (Mark Wielaard 2023-10-30 23:30:06 +0100 1724) #endif
>
> Try using Valgrind 3.23 and see if the problem goes away.
yeah, that was the workaround for this bug.
But that simply means we don't do any overlap checking on x86_64, which is
still a bug :{
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 488379] --track-fds=yes generates errors that cannot be suppressed for valgrind internal --xml-file=
https://bugs.kde.org/show_bug.cgi?id=488379 Mark Wielaard changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||ahajk...@redhat.com, ||m...@klomp.org Summary|--track-fds=yes generates |--track-fds=yes generates |errors that cannot be |errors that cannot be |suppressed |suppressed for valgrind ||internal --xml-file= --- Comment #1 from Mark Wielaard --- yes, --track-fds obviously should ignore the --xml-file=xxx file descriptors. Thanks for reporting. Will investigate. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 487862] memcheck does not believe that bytes on new pages are Defined by brk() system call
https://bugs.kde.org/show_bug.cgi?id=487862 --- Comment #9 from Mark Wielaard --- Hi John, (In reply to John Reiser from comment #8) > What has changed is very large apps such as qemu-user-* which depend on > dozens of "random" libraries, and the system > builders/maintainers/administrators > who tired of their own version of "dll hell" due to dependency tracking, > and the users (including "systematic" users with scripts) who got tired of > multi-second initialization of all those shared libraries; all gained new > appreciation > for -static builds of ET_EXEC (no shared libraries at all!) which > initialize in a flash > and have robust configuration (none!) for end users. Disk space is cheap > for many > such users; time is not. qemu-user has grown into a predictable evolution > which > avoids nearly all "security" incidents which otherwise might argue for using > shared libraries. Interesting, but is this still about how to handle the brk syscall? It sound like a separate issue that valgrind doesn't support static linked binaries (because we cannot use the LD_PRELOAD trick to get our alternative malloc/mem/str implementations loaded). There seem to be some alternate bugs about that. https://bugs.kde.org/show_bug.cgi?id=198248 https://bugs.kde.org/show_bug.cgi?id=406434 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 487862] memcheck does not believe that bytes on new pages are Defined by brk() system call
https://bugs.kde.org/show_bug.cgi?id=487862 --- Comment #6 from Mark Wielaard --- BTW it seems this whole discussion is duplicated in the comments of memcheck/mc_main.c mc_post_clo_init () // We assume that brk()/sbrk() does not initialise new memory. ... With as conclusion: // So we should arguably observe all this. However: // - The current inaccuracy has caused maybe one complaint in seven years(?) // - Relying on the zeroed-ness of whole brk'd pages is pretty grotty... I // doubt most programmers know the above information. // So I'm not terribly unhappy with marking it as undefined. --njn. Which was written in 2009. So maybe times have changed since then. But I don't really remember any false positive report about this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 487862] memcheck does not believe that bytes on new pages are Defined by brk() system call
https://bugs.kde.org/show_bug.cgi?id=487862 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #4 from Mark Wielaard --- (In reply to John Reiser from comment #0) > On Linux, when the brk() system call adds new pages to the address space, > then those pages are guaranteed to be all-zero, but memcheck thinks the > bytes are Undefined. I think this is the basic problem. It says if it adds "new pages" then those pages are guaranteed to be all-zero. But if the pages already existed and brk() just gives them back those aren't guaranteed to be all-zero but can contain whatever was there before. Also note that the man7 manpage for brk() nor the glibc manual make any claims about the memory area being initialized: https://man7.org/linux/man-pages/man2/brk.2.html https://sourceware.org/glibc/manual/latest/html_node/Resizing-the-Data-Segment.html So it seems reasonable for memcheck to assume the area exposed by brk() is undefined. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 487439] SIGILL in JDK11, JDK17
https://bugs.kde.org/show_bug.cgi?id=487439
--- Comment #10 from Mark Wielaard ---
(In reply to Paul Floyd from comment #9)
> diff --git a/VEX/priv/guest_amd64_toIR.c b/VEX/priv/guest_amd64_toIR.c
> index f0b1c5516..28c37f092 100644
> --- a/VEX/priv/guest_amd64_toIR.c
> +++ b/VEX/priv/guest_amd64_toIR.c
> @@ -14138,7 +14138,7 @@ Long dis_ESC_0F__SSE2 ( Bool* decode_OK,
> goto decode_success;
>}
>/* 66 0F 73 /6 ib = PSLLQ by immediate */
> - if (have66noF2noF3(pfx) && sz == 2
> + if (have66noF2noF3(pfx) && (sz == 2 || /* ignore redundant REX.W */
> sz == 8)
>&& epartIsReg(getUChar(delta))
>&& gregLO3ofRM(getUChar(delta)) == 6) {
> delta = dis_SSE_shiftE_imm( pfx, delta, "psllq", Iop_ShlN64x2 );
>
> Mark, do you know how to force using rex.W in assembler?
It looks like binutils gas allows you to use rex.W as prefix, so:
rex.W psllq $12, %xmm1
The documentation is a little confusing though (I am not sure whether W should
be seen as X, Y and Z extension bit or not):
https://sourceware.org/binutils/docs/as/i386_002dPrefixes.html
The ‘rex’ family of prefixes is used by x86-64 to encode extensions to i386
instruction set. The ‘rex’ prefix has four bits — an operand size overwrite
(64) used to change operand size from 32-bit to 64-bit and X, Y and Z
extensions bits used to extend the register set.
You may write the ‘rex’ prefixes directly. The ‘rex64xyz’ instruction emits
‘rex’ prefix with all the bits set. By omitting the 64, x, y or z you may write
other prefixes as well. Normally, there is no need to write the prefixes
explicitly, since gas will automatically generate them based on the instruction
operands.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 487439] SIGILL in JDK11, JDK17
https://bugs.kde.org/show_bug.cgi?id=487439 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #8 from Mark Wielaard --- (In reply to Paul Floyd from comment #5) > This looks like > 66 48 0f 73 f1 0c rex.W psllq xmm1,0xc > > Some more from the log > > vex amd64->IR: unhandled instruction bytes: 0x66 0x48 0xF 0x73 0xF1 0xC 0x66 > 0xF 0x70 0xF5 > vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 > vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F > vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 > > "psllq" should be handled, but it looks like it's the REX prefix that is > causing the problem. I think we can just ignore the REX prefix. The intel 64 and IA-32 Architectures Software Developer’s Manual section 10.2.1 "Intel SSE in 64-Bit Mode and Compatibility Mode" says: "In 64-bit mode, eight additional XMM registers are accessible. Registers XMM8-XMM15 are accessed by using REX prefixes. Memory operands are specified using the ModR/M, SIB encoding described in Section 3.7.5. Some Intel SSE instructions may be used to operate on general-purpose registers. Use the REX.W prefix to access 64-bit general-purpose registers. Note that if a REX prefix is used when it has no meaning, the prefix is ignored." -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 487296] --track-fds=yes and --track-fds=all report erroneous information when fds 0, 1, or 2 are used as non-std
https://bugs.kde.org/show_bug.cgi?id=487296 --- Comment #3 from Mark Wielaard --- For each inherited fd VG_(init_preopened_fds) calls ML_(record_fd_open_named)(-1, fd); So the ThreadId will be -1. Which ML_(record_fd_open_with_given_name) documents as "If the tid is -1, this indicates an inherited fd." Which in practice means the struct OpenFd where field will be set to NULL ExeContext *where; /* NULL if inherited from parent */ So what we could probably do, instead of having a special static Bool std_fds[3], is checking for where == NULL instead. Which would handle all inherited file descriptors, not just 0, 1, 2. Does that make sense? Would that be useful? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 487296] --track-fds=yes and --track-fds=all report erroneous information when fds 0, 1, or 2 are used as non-std
https://bugs.kde.org/show_bug.cgi?id=487296 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #2 from Mark Wielaard --- Treating the std fds as "generic" inherited fds would also handle the case where a program is started with stdin/out/err already closed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 487296] --track-fds=yes and --track-fds=all report erroneous information when fds 0, 1, or 2 are used as non-std
https://bugs.kde.org/show_bug.cgi?id=487296 --- Comment #1 from Mark Wielaard --- Nice. Thanks for catching this. Yeah, it makes sense to start "tracking" std fds once they are closed (and reopened). One thought I had was that maybe this shouldn't be special cased for just stdin/out/err (0,1,2). It seems to me that those are just a special case of inherited file descriptors. Currently out testcases themselves "cheat". We have some special CLOSE_INHERITED_FDS macro in there to shut valgrind --track-fds up about any file descriptors the tests might inherit (some versions of perl "leak" them in out testsuite). We could track those, together with 0, 1, 2 through VG_(init_preopened_fds) at program startup. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 487296] --track-fds=yes and --track-fds=all report erroneous information when fds 0, 1, or 2 are used as non-std
https://bugs.kde.org/show_bug.cgi?id=487296 Mark Wielaard changed: What|Removed |Added CC||ahajk...@redhat.com, ||m...@klomp.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 317127] Fedora18/x86_64 --sanity-level=3 : aspacem segment mismatch
https://bugs.kde.org/show_bug.cgi?id=317127 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #18 from Mark Wielaard --- I must admit I don't fully understand what we are trying to do. As far as I understand it, the idea is that we sanity check what the aspacemgr records against what /proc/self/maps shows? But that includes some device specific inode values which we don't have/know? Can't we just make cmp_devino = False the default? aka never check those? Or are we loosing some valuable sanity checks/info that way? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 486180] [Valgrind][MIPS] 'VexGuestArchState' has no member named 'guest_IP_AT_SYSCALL'
https://bugs.kde.org/show_bug.cgi?id=486180
Mark Wielaard changed:
What|Removed |Added
CC||ar...@linux.ibm.com
--- Comment #7 from Mark Wielaard ---
I don't really like the suggested fix in comment #6 (commit 721488688).
It is not clear to me that all arches use guest_IP_AT_SYSCALL is the same way.
The current use only really is known to work for s390x.
So I would propose something like:
diff --git a/coregrind/m_scheduler/scheduler.c
b/coregrind/m_scheduler/scheduler.c
index fc8cf7c9cb1d..6ce3551b2be9 100644
--- a/coregrind/m_scheduler/scheduler.c
+++ b/coregrind/m_scheduler/scheduler.c
@@ -1225,6 +1225,15 @@ static void handle_syscall(ThreadId tid, UInt trc)
}
}
+static Addr sig_ill_addr_extension (ThreadState *tst)
+{
+#if defined(VGA_s390x)
+ return tst->arch.vex.guest_IP_AT_SYSCALL;
+#else
+ VG_(core_panic)("scheduler: sig_ill_addr_extension: unhandled arch");
+#endif
+}
+
static void handle_extension(ThreadId tid)
{
volatile UWord jumped;
@@ -1235,7 +1244,7 @@ static void handle_extension(ThreadId tid)
if (err != ExtErr_OK) {
ThreadState* tst = VG_(get_ThreadState)(tid);
- Addr addr = tst->arch.vex.guest_IP_AT_SYSCALL;
+ Addr addr = sig_ill_addr_extension (tst);
switch (err) {
case ExtErr_Illop:
VG_(synth_sigill)(tid, addr);
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 486293] New: memccpy false positives
https://bugs.kde.org/show_bug.cgi?id=486293
Bug ID: 486293
Summary: memccpy false positives
Classification: Developer tools
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: m...@klomp.org
CC: pjfl...@wanadoo.fr
Target Milestone: ---
The length of the src area is calculated wrongly in the memccpy replace
function. This causes a false positive overlap warning when the c character is
found early in the src memory area. Fix this by making sure the srclen is
calculated correctly (only covers the area of bytes actually copied). And add a
new testcase in memcheck/tests/memccpy2.c that fails (shows a false positive)
with the old implementation, but passes with the new implementation of the
memccpy replacement function.
diff --git a/memcheck/tests/memccpy2.c b/memcheck/tests/memccpy2.c
index a5a1dfc9f0af..4a54e04c0ae6 100644
--- a/memcheck/tests/memccpy2.c
+++ b/memcheck/tests/memccpy2.c
@@ -9,5 +9,7 @@ int main(void)
memccpy(astring+10, astring, '#', len-10);
sprintf(astring, "this is a string # with something to seek");
memccpy(astring, astring+10, '#', len);
+ sprintf(astring, "this is a string # with something to seek");
+ memccpy(astring+10, astring, ' ', len-10); /* space is early, no overlap */
}
diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c
index 737abbf67898..036763efcf0c 100644
--- a/shared/vg_replace_strmem.c
+++ b/shared/vg_replace_strmem.c
@@ -2364,9 +2364,9 @@ static inline void my_exit ( int x )
\
while (i-- > 0) \
if ((*d++ = *s++) == x) { \
-SizeT srclen = (i < len) ? i : len; \
+SizeT srclen = (i < len) ? len - i : len; \
RECORD_COPY(srclen); \
-if (is_overlap(dst, src, srclen, srclen)) \
+if (is_overlap(dst, src, len, srclen)) \
RECORD_OVERLAP_ERROR("memccpy", dst, src, len); \
return d; \
} \
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 486180] [Valgrind][MIPS] 'VexGuestArchState' has no member named 'guest_IP_AT_SYSCALL'
https://bugs.kde.org/show_bug.cgi?id=486180 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #5 from Mark Wielaard --- Urgh, this is unfortunate. We didn't have a mips builder and didn't find this during CI testing. This should probably have been implemented as VG_(client_extension) see coregrind/m_extension/extension-main.c which is only done for s390x now. There is precedent in fixup_guest_state_to_restart_syscall -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362680] --error-exitcode not honored when file descriptor leaks are found
https://bugs.kde.org/show_bug.cgi?id=362680 Mark Wielaard changed: What|Removed |Added CC||v...@altlinux.org --- Comment #6 from Mark Wielaard --- *** Bug 482358 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 482358] Feature Request: Add --track-fds=error
https://bugs.kde.org/show_bug.cgi?id=482358 Mark Wielaard changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #3 from Mark Wielaard --- *** This bug has been marked as a duplicate of bug 362680 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485924] No support for pidfd_send_signal system call
https://bugs.kde.org/show_bug.cgi?id=485924 --- Comment #3 from Mark Wielaard --- So the only tricky part is that we want to mimic this part of the (generic) PRE(sys_kill): /* If we're sending SIGKILL, check to see if the target is one of our threads and handle it specially. */ if (ARG2 == VKI_SIGKILL && ML_(do_sigkill)(ARG1, -1)) SET_STATUS_Success(0); In the pidfd_send_signal case ARG2 is the signo, just like the kill syscall. But ARG1 is a pidfd and do_sigkill wants an pid (tid). So we have to somehow translate the pidfd to a pid number. It isn't immediately clear how to do that. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485924] No support for pidfd_send_signal system call
https://bugs.kde.org/show_bug.cgi?id=485924 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED CC||m...@klomp.org --- Comment #2 from Mark Wielaard --- There was a preliminary implementation posted to the mailinglist: https://sourceforge.net/p/valgrind/mailman/message/52515225/ -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485778] Crash with --track-fds=all and --gen-suppressions=all
https://bugs.kde.org/show_bug.cgi?id=485778 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #4 from Mark Wielaard --- commit d68d584cead390c339b9575c5c9679e8ce50c37f Author: Mark Wielaard Date: Fri Apr 19 22:46:11 2024 +0200 core errors suppression support Add two new functions core_get_extra_suppression_info and core_get_error_name as alternatives for tool suppression callbacks. These functions are used in gen_suppression. Instead of a tool name, a core error component name is "CoreError". Two new suppression kinds FdBadCloseSupp and FdNotClosedSupp were added. Corresponding to the FdBadClose and FdNotClosed error kinds. core_error_matches_suppression matches these suppression kinds with error kinds. core_get_extra_suppression_info and core_print_extra_suppression_use are noops for core errors. is_suppressible_error, supp_matches_error, load_one_suppressions_file and show_used_suppressions have been adjusted to work with core error kinds. A new function VG_(found_or_suppressed_errs) helps to not output an empty error summary if only core errors are requested, but no errors were detected. VG_(clo_track_fds) has been moved from pub_core_options.h to pub_tool_options.h. And VG_(needs_core_errors) now takes a Bool that can be set to false in the tool post_clo_init handler. This is used in the none tool to request core errors, but disable all reporting if no option has been given that enables such errors. This make sure only the none/tests/fdleak_ipv4.stderr.exp needs adjustment. For all other tests the output is exactly as before. https://bugs.kde.org/show_bug.cgi?id=485778 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485778] Crash with --track-fds=all and --gen-suppressions=all
https://bugs.kde.org/show_bug.cgi?id=485778
Mark Wielaard changed:
What|Removed |Added
Attachment #168679|0 |1
is obsolete||
--- Comment #3 from Mark Wielaard ---
Created attachment 168690
--> https://bugs.kde.org/attachment.cgi?id=168690=edit
core errors suppression support
This version handles both generating and using suppressions. So now you can
also add something like:
{
core-bad-close
CoreError:FdBadClose
fun:close
fun:closefile
fun:main
}
And it will suppress the error as expected.
It also adds VG_(needs_core_errors) to all tools that support tool_errors and
to the none tool.
No testcases yet though
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 485778] Crash with --track-fds=all and --gen-suppressions=all
https://bugs.kde.org/show_bug.cgi?id=485778
--- Comment #2 from Mark Wielaard ---
Created attachment 168679
--> https://bugs.kde.org/attachment.cgi?id=168679=edit
core errors gensuppressions support
Initial implementation for --gen-suppressions support for core errors
With this the testcase ../../vg-in-place --track-fds=all --tool=none
--gen-suppressions=all ./fdleak_creat produces:
==381147== Bad option: --gen-suppressions=yes
==381147== Can't use --gen-suppressions= with Nulgrind
==381147== because it doesn't generate errors.
==381147== Use --help for more information or consult the user manual.
==381147== Nulgrind, the minimal Valgrind tool
==381147== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote.
==381147== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright
info
==381147== Command: ./fdleak_creat
==381147==
==381147==
==381147== FILE DESCRIPTORS: 4 open (3 std) at exit.
==381147== Open file descriptor 3: /tmp/file.381147
==381147==at 0x495B9C4: creat (creat64.c:28)
==381147==by 0x401249: main (fdleak_creat.c:13)
==381147==
{
CoreError:FdNotClosed
fun:creat
fun:main
}
==381147== Open file descriptor 2: /dev/pts/4
==381147==
==381147==
==381147== (No origin, error cannot be suppressed)
==381147== Open file descriptor 1: /dev/pts/4
==381147==
==381147==
==381147== (No origin, error cannot be suppressed)
==381147== Open file descriptor 0: /dev/pts/4
==381147==
==381147==
==381147== (No origin, error cannot be suppressed)
==381147==
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 485778] Crash with --track-fds=all and --gen-suppressions=all
https://bugs.kde.org/show_bug.cgi?id=485778 Mark Wielaard changed: What|Removed |Added Assignee|jsew...@acm.org |m...@klomp.org Status|REPORTED|CONFIRMED CC||ahajk...@redhat.com, ||m...@klomp.org Ever confirmed|0 |1 --- Comment #1 from Mark Wielaard --- (In reply to Paul Floyd from comment #0) > Are we planning on adding suppressions to core errors? If so this message > will also need to change: > ==32134== Bad option: --gen-suppressions=yes > ==32134== Can't use --gen-suppressions= with Nulgrind > ==32134== because it doesn't generate errors. > ==32134== Use --help for more information or consult the user manual. > > (it says it can't use it and then it does use it!) There are a couple of extra callbacks needed to support suppressions for core errors. But they shouldn't be hard to add. There also needs to be a special check for core errors that have a NULL where (e.g. when reporting with --track-fds=all on inherited file descriptors). Working on it now. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 328563] make track-fds support xml output
https://bugs.kde.org/show_bug.cgi?id=328563 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #7 from Mark Wielaard --- commit 09b5ad416c5ddf1375f269f6ea2253e90fa08f01 Author: Alexandra Hájková Date: Thu Apr 18 05:21:49 2024 -0400 Improve file descriptor xml output, add fd and path elements Add needs_xml_output to none tool so it can also output xml when --track-fds enabled. Use xml protocolversion 5 when clo_track_fds is enabled Split OpenFD pathname and description. Add description when a file descriptor is closed so it can be used in a future error. On error print element and (if known) a element. Add docs/internals/xml-output-protocol5.txt. https://bugs.kde.org/show_bug.cgi?id=328563 Co-Authored-By: Mark Wielaard -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362680] --error-exitcode not honored when file descriptor leaks are found
https://bugs.kde.org/show_bug.cgi?id=362680 Mark Wielaard changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Mark Wielaard --- commit 34e9e4957ada1ba0a51266faee23f61724935fcb Author: Mark Wielaard Date: Wed Mar 20 01:44:23 2024 -0400 Add core errors and use them to implement file descriptor tracker All the tool error callbacks now have a core error equivalent. core errors are negative (while tool errors are positive). There are two new ones for tracking issues with file descriptors. FdBadClose (-2) and FdNotClosed (-3). Add following core error functions with delegates to file descriptor specific functions (implemented in syswrap-generic): - core_eq_Error (fd_eq_Error) Compares core errors to detect duplicates - core_before_pp_Error (fd_before_pp_Error) Currently prints nothing for known core errors and exists with FATAL for unknown core errors - core_pp_Error (fd_pp_Error) For FdBadClose prints the backtraces for the file descriptor was opened, where it was originally closed and where it was closed again. For FdNotClosed prints where the file descriptor was opened. - core_update_extra (fd_update_extra) Returns the size of the BadCloseExtra or FdNotClosedExtra struct which data needs to be saved (the fd number, pathname/description and previous backtraces). We now accept the error (ExeContext) where to be NULL. This is necessary for reporting not closed file descriptors when the descriptor is inherited from the parent (so wasn't actually created and doesn't have a 'where' in the current process code). All the testcases still pass since the (stderr) output is the same. But now they count as "real" errors. And so --error-exitcode does now also work for file descriptor errors or leaks. https://bugs.kde.org/show_bug.cgi?id=362680 Co-authored-by: Alexandra Hájková -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362680] --error-exitcode not honored when file descriptor leaks are found
https://bugs.kde.org/show_bug.cgi?id=362680 --- Comment #4 from Mark Wielaard --- bug #328563 has an attachment that implements this -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450705] s390x: Add NNPA support (arch14)
https://bugs.kde.org/show_bug.cgi?id=450705 --- Comment #8 from Mark Wielaard --- (In reply to Andreas Arnez from comment #7) > (In reply to Andreas Arnez from comment #6) > > Created attachment 168623 [details] > > Updated version of the extension proposal > I pushed this now, as a preparation to adding NNPA support. If there are > still any issues with this, please let me know. Looks good on both x86_64 and s390x (both fedora 39). On s390x the ppno.vgtest succeeds. x86_64 had zero failures. s390x had one failure (also before you patch): drd/tests/tc04_free_lock (stderr) I did push two small fixups: commit 02bca4fa3a62dafbc8f051a0f766f9d5763f6e1c Author: Mark Wielaard Date: Thu Apr 18 15:58:37 2024 +0200 Add pub_core_extension.h to coregrind/Makefile.am noinst_HEADERS commit 381e2a25fbf8e7d16d66851a5d0e1f919cf69505 (HEAD -> master) Author: Mark Wielaard Date: Thu Apr 18 17:45:16 2024 +0200 Don't include pub_tool_tooliface.h in priv_types_n_macros.h post-regtest-checks complains: *** File coregrind/m_extension/priv_types_n_macros.h must not include pub_tool_tooliface.h Which isn't really necessary anyway since priv_types_n_macros.h already includes pub_core_tooliface.h. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450705] s390x: Add NNPA support (arch14)
https://bugs.kde.org/show_bug.cgi?id=450705
--- Comment #5 from Mark Wielaard ---
I haven't reviewed the fully proposal, but in general I like the idea of using
the same mechanism as the syscalls for instrumenting these more complex
instructions. It is at least familiar. You might want to rename
guest_IP_AT_SYSCALL (it looks like it has the right semantics, but looks funny)
and you might want to look at what defines VG_(client_extension). Currently it
is only defined for s390x, so building scheduler.c will break on any other
arch. It should probably be its own function inside scheduler.c with something
like #if defined(VGA_s390x) x390x_... #else VG_(core_panic)("arch doesn't
implement...") #endif.
It would be nice to get this in this week so it makes valgrind -3.23.0-RC1 and
can get a bit wider testing.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 450705] s390x: Add NNPA support (arch14)
https://bugs.kde.org/show_bug.cgi?id=450705 --- Comment #3 from Mark Wielaard --- Extension idea was posted to the mailinglist: https://sourceforge.net/p/valgrind/mailman/message/58753610/ -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485276] std::optional use: "Conditional jump or move depends on uninitialised value(s)" (clang) aarch64
https://bugs.kde.org/show_bug.cgi?id=485276 --- Comment #4 from Mark Wielaard --- (In reply to Mark Wielaard from comment #3) > I am unable to replicate this with either clang version 17.0.6 or 18.1.2, > not with -O2 or -O1. On x86_64. Missed that the original report was against arm64 (sorry). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485276] std::optional use: "Conditional jump or move depends on uninitialised value(s)" (clang) aarch64
https://bugs.kde.org/show_bug.cgi?id=485276 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #3 from Mark Wielaard --- I am unable to replicate this with either clang version 17.0.6 or 18.1.2, not with -O2 or -O1. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 472329] std::optional use: "Conditional jump or move depends on uninitialised value(s)" (g++)
https://bugs.kde.org/show_bug.cgi?id=472329 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 CC||m...@klomp.org Status|REPORTED|CONFIRMED --- Comment #8 from Mark Wielaard --- I can replicate with the code of comment #4 and g++ 13.2.1 or 14.0.1 (prerelease) but only with -O1. -O0 and -O2 don't show the issue. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #17 from Mark Wielaard --- .git-blame-ignore-revs references a clang-format rev that doesn't exist in tree. Makefile.all.am and Makefile.tool.am look correct. NEWS OK. VEX changes OK, except for unnecessarily extending VexGuestARM64State for non-freebsd systems. Would be really nice if that VEX/auxprogs/genoffsets.c GENOFFSET(ARM64,arm64,SETC); could only be done of freebsd. configure.ac looks OK (but not a fan of the reindentations, it makes looking for the actual changes a bit of a pain) coregrind/launcher-freebsd.c OK coregrind/m_aspacemgr changes OK (aspacemgr-linux.c is clearly a bad name, but lets not rename it for now). coregrind/m_coredump/coredump-elf.c looks correct (do we have any tests for this? I don't believe we do). coregrind/m_debuginfo changes look OK. coregrind/m_debuglog.c dunno why there is a clang and gcc variant of local_sys_write_stderr. One uses SizeT the other Unt (should be Int). coregrind/m_dispatch/dispatch-arm64-freebsd.S Not sure I am qualified to review this voodoo. coregrind/m_initimg/initimg-freebsd.c looks OK coregrind/m_libcassert.c, coregrind/m_libcfile.c, coregrind/m_libcsetjmp.c OK -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485487] glibc built with -march=x86-64-v3 does not work due to ld.so strcmp
https://bugs.kde.org/show_bug.cgi?id=485487 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #9 from Mark Wielaard --- commit dad279b80c1da4fb2c842cca9783ad0e49339ddc Author: Florian Weimer Date: Sun Apr 14 21:56:03 2024 +0200 add_hardwired_spec for ld-linux-x86-64.so.2 strcmp glibc built with -march=x86-64-v3 does not work due to ld.so strcmp https://bugs.kde.org/show_bug.cgi?id=485487 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485487] glibc built with -march=x86-64-v3 does not work due to ld.so strcmp
https://bugs.kde.org/show_bug.cgi?id=485487 --- Comment #7 from Mark Wielaard --- There is now also an fedora eln build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2437715 Since eln is build with -march=x86-64-v3 this might be a good testing environment. Please let me know if you are able to build/test a glibc against one of the above packages with this patch applied. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485487] glibc built with -march=x86-64-v3 does not work due to ld.so strcmp
https://bugs.kde.org/show_bug.cgi?id=485487 --- Comment #6 from Mark Wielaard --- (In reply to Mark Wielaard from comment #5) > I'll add it to the next fedora rawhide valgrind build so we can test it a > bit more. There is now valgrind-3.22.0-8.fc41 with this and some other (x86-64-v3) fixes to try out. https://bodhi.fedoraproject.org/updates/FEDORA-2024-7579427715 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485487] glibc built with -march=x86-64-v3 does not work due to ld.so strcmp
https://bugs.kde.org/show_bug.cgi?id=485487 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #5 from Mark Wielaard --- (In reply to Florian Weimer from comment #4) > Based on a further suggestion from H.J., I put the strcmp implementation > posted here into glibc and ran its strcmp test suite against it. It passes. > For such a simple implementation it should have really good coverage. So I > think the posted implementation should be okay. Yes. The license would be fine. But simpler is actually better for valgrind. The code will run on the virtual machine and will be instrumented by tools. I'll add it to the next fedora rawhide valgrind build so we can test it a bit more. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485487] glibc built with -march=x86-64-v3 does not work due to ld.so strcmp
https://bugs.kde.org/show_bug.cgi?id=485487 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- The proposed patch looks reasonable. Did you test it? Is there a (fedora?) glibc build that triggers this issue? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 463458] memcheck/tests/vcpu_fnfns fails when glibc is built for x86-64-v3 target
https://bugs.kde.org/show_bug.cgi?id=463458 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit a5693c1203c3a26443af13182a8082c2e9152f6c Author: Mark Wielaard Date: Sat Apr 13 14:33:19 2024 +0200 amd64: Implement VFMADD213 for Iop_MAddF32 and Iop_MAddF64 Speed up F32 and F64 FMA on amd64. Add priv/host_amd64_maddf.c implementing h_amd64_calc_MAddF32_fma4 and h_amd64_calc_MAddF64_fma4 to be used instead of the generic variants h_generic_calc_MAddF32 and h_generic_calc_MAddF64 when host has VEX_HWCAPS_AMD64_FMA4. Add fma3 and fma4 detection m_machine.c (machine_get_hwcaps). This patch also fixes the memcheck/tests/vcpu_fnfns and none/tests/amd64/fma testcases when run on a x86-64-v3 system. Patch contributed by Grazvydas Ignotas and Bruno Lathuilière https://bugs.kde.org/show_bug.cgi?id=481127 https://bugs.kde.org/show_bug.cgi?id=463463 https://bugs.kde.org/show_bug.cgi?id=463458 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 463463] none/tests/amd64/fma fails when executed under valgrind on a x86-64-v3 system
https://bugs.kde.org/show_bug.cgi?id=463463 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #3 from Mark Wielaard --- commit a5693c1203c3a26443af13182a8082c2e9152f6c Author: Mark Wielaard Date: Sat Apr 13 14:33:19 2024 +0200 amd64: Implement VFMADD213 for Iop_MAddF32 and Iop_MAddF64 Speed up F32 and F64 FMA on amd64. Add priv/host_amd64_maddf.c implementing h_amd64_calc_MAddF32_fma4 and h_amd64_calc_MAddF64_fma4 to be used instead of the generic variants h_generic_calc_MAddF32 and h_generic_calc_MAddF64 when host has VEX_HWCAPS_AMD64_FMA4. Add fma3 and fma4 detection m_machine.c (machine_get_hwcaps). This patch also fixes the memcheck/tests/vcpu_fnfns and none/tests/amd64/fma testcases when run on a x86-64-v3 system. Patch contributed by Grazvydas Ignotas and Bruno Lathuilière https://bugs.kde.org/show_bug.cgi?id=481127 https://bugs.kde.org/show_bug.cgi?id=463463 https://bugs.kde.org/show_bug.cgi?id=463458 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481127] [PATCH] amd64: Implement VFMADD213 for Iop_MAddF32
https://bugs.kde.org/show_bug.cgi?id=481127 Mark Wielaard changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Mark Wielaard --- commit a5693c1203c3a26443af13182a8082c2e9152f6c Author: Mark Wielaard Date: Sat Apr 13 14:33:19 2024 +0200 amd64: Implement VFMADD213 for Iop_MAddF32 and Iop_MAddF64 Speed up F32 and F64 FMA on amd64. Add priv/host_amd64_maddf.c implementing h_amd64_calc_MAddF32_fma4 and h_amd64_calc_MAddF64_fma4 to be used instead of the generic variants h_generic_calc_MAddF32 and h_generic_calc_MAddF64 when host has VEX_HWCAPS_AMD64_FMA4. Add fma3 and fma4 detection m_machine.c (machine_get_hwcaps). This patch also fixes the memcheck/tests/vcpu_fnfns and none/tests/amd64/fma testcases when run on a x86-64-v3 system. Patch contributed by Grazvydas Ignotas and Bruno Lathuilière https://bugs.kde.org/show_bug.cgi?id=481127 https://bugs.kde.org/show_bug.cgi?id=463463 https://bugs.kde.org/show_bug.cgi?id=463458 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481127] [PATCH] amd64: Implement VFMADD213 for Iop_MAddF32
https://bugs.kde.org/show_bug.cgi?id=481127 --- Comment #10 from Mark Wielaard --- Created attachment 168440 --> https://bugs.kde.org/attachment.cgi?id=168440=edit valgrind.fma_arm64.diff This is the variant of the patch that I tested. It looks good to me. How should we credit this when applying? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481127] [PATCH] amd64: Implement VFMADD213 for Iop_MAddF32
https://bugs.kde.org/show_bug.cgi?id=481127 Mark Wielaard changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||m...@klomp.org --- Comment #9 from Mark Wielaard --- On a distro compiled with gcc -march=x86-64-v3 this patch fixes: bug #463463 none/tests/amd64/fma bug #463458 memcheck/tests/vcpu_fnfns -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 463458] memcheck/tests/vcpu_fnfns fails when glibc is built for x86-64-v3 target
https://bugs.kde.org/show_bug.cgi?id=463458 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- Confirmed. But also seems to be fixed with the patch from https://bugs.kde.org/show_bug.cgi?id=481127 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 463456] memcheck/tests/origin6-fp fails when building for x86-64-v3 target
https://bugs.kde.org/show_bug.cgi?id=463456 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- Confirmed. With gcc -march=x86-64-v3 memcheck is unable to track the origin. Even when build with -O0 (instead of -O). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 463463] none/tests/amd64/fma fails when executed under valgrind on a x86-64-v3 system
https://bugs.kde.org/show_bug.cgi?id=463463 --- Comment #2 from Mark Wielaard --- These seem rounding issues, fixed by https://bugs.kde.org/show_bug.cgi?id=481127 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 463463] none/tests/amd64/fma fails when executed under valgrind on a x86-64-v3 system
https://bugs.kde.org/show_bug.cgi?id=463463 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- I am also seeing this. It seems to depend on glibc being compiled with -march=x86-64-v3. If only the fma testcase is compiled with gcc -march=x86-64-v3 but the rest of the system is not, then the testcase does pass under valgrind. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 377966] arm64 unhandled instruction dc zva
https://bugs.kde.org/show_bug.cgi?id=377966 Mark Wielaard changed: What|Removed |Added Summary|Error message said to |arm64 unhandled instruction |report |dc zva -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 479600] Segmentation fault launching the valgrind (mipsel-openwrt-linux-musl-gcc)
https://bugs.kde.org/show_bug.cgi?id=479600 Mark Wielaard changed: What|Removed |Added Summary|Segmentation fault |Segmentation fault |launching the valgrind |launching the valgrind ||(mipsel-openwrt-linux-musl- ||gcc) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #9 from Mark Wielaard --- This is such a huge patch that I don't really know where to start. Can this be split up a little? Maybe have the changes needed to compile with clang instead of gcc separate from the rest? Or does freebsd arm64 only support building with clang? Likewise maybe separate the VEX/corgrind stuff from the tools and the tests? I randomly looked at the sbrk changes for the testcases. Which seems necessary because freebsd doesn't have sbrk on arm64 or riscv. That configure check and disabling of dw4 and pages_as_heap seem fine. In VEX. What are the priv/guest_arm64_toIR.c changes for? You need LibVEX_GuestARM64_put_nzcv_c to signal syscall success/failure. I am not fully clear what the guest_SETC is for. The guest_SC_CLASS seems to be to determine how syscall numbers are passed. Would it make sense to only include those fields, and padding, for freebsd? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484426] aarch64: 0.5 gets rounded to 0
https://bugs.kde.org/show_bug.cgi?id=484426 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #6 from Mark Wielaard --- This looks good to me. But I have not tested it. And I have to trust you on the emit code (too lazy to look up the instr enc) It looks like none/tests/arm64/fp_and_simd.c already has tests for both frinti and frinta. Did they just happen to work just fine with the existing code? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
https://bugs.kde.org/show_bug.cgi?id=484002
--- Comment #5 from Mark Wielaard ---
Comment on attachment 167483
--> https://bugs.kde.org/attachment.cgi?id=167483
first attempt at a patch
Very nice.
Before the patch:
$ ~/src/valgrind/vg-in-place ./t
==66177== Memcheck, a memory error detector
==66177== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==66177== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright
info
==66177== Command: ./t
==66177==
0x1ffefff9f0 0x1ffefff9e0
3
0x4a58480 0x1ffefff9e0
3
0x4a584d0 0x1ffefff9e0
==66177== Invalid read of size 32
==66177==at 0x49D6A2E: __wcpncpy_avx2 (strncpy-avx2.S:85)
==66177==by 0x4938560: wcsxfrm_l (strxfrm_l.c:679)
==66177==by 0x4012A1: main (t.c:25)
==66177== Address 0x4a584d0 is 0 bytes inside a block of size 16 alloc'd
==66177==at 0x484278B: malloc (vg_replace_malloc.c:446)
==66177==by 0x401258: main (t.c:22)
==66177==
3
==66177==
==66177== HEAP SUMMARY:
==66177== in use at exit: 0 bytes in 0 blocks
==66177== total heap usage: 3 allocs, 3 frees, 1,056 bytes allocated
==66177==
==66177== All heap blocks were freed -- no leaks are possible
==66177==
==66177== For lists of detected and suppressed errors, rerun with: -s
==66177== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
After the patch:
$ ~/src/valgrind/vg-in-place ./t
==67120== Memcheck, a memory error detector
==67120== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==67120== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright
info
==67120== Command: ./t
==67120==
0x1ffefff9e0 0x1ffefff9d0
3
0x4a58480 0x1ffefff9d0
3
0x4a584d0 0x1ffefff9d0
3
==67120==
==67120== HEAP SUMMARY:
==67120== in use at exit: 0 bytes in 0 blocks
==67120== total heap usage: 3 allocs, 3 frees, 1,056 bytes allocated
==67120==
==67120== All heap blocks were freed -- no leaks are possible
==67120==
==67120== For lists of detected and suppressed errors, rerun with: -s
==67120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Implementation looks correct. Two small comments.
+ /* This checks for overlap after copying, unavoidable without */ \
+ /* pre-counting length... should be ok */ \
+ /* +4 because sizeof(wchar_t) == 4 */ \
+ SizeT srclen = ((m < n) ? m+1 : n)*4; \
+ RECORD_COPY(srclen); \
I found the comment a little confusing until I understood that the +4 really
meant *4.
+ RECORD_OVERLAP_ERROR("wcspcpy", dst_orig, src_orig, 0); \
^wcpncpy
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
https://bugs.kde.org/show_bug.cgi?id=484002 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #2 from Mark Wielaard --- We already have an override for wcsncpy and stpncpy. But not wcpncpy. See shared/vg_replace_strmem.c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 483711] -m32 flag breaks Valgrind
https://bugs.kde.org/show_bug.cgi?id=483711
Mark Wielaard changed:
What|Removed |Added
CC||m...@klomp.org
--- Comment #5 from Mark Wielaard ---
Various x86_64 (amd64) builders on builder.sourceware.org are docker based. I
think valgrind works fine under a linux container/docker setup. But none of
them run x86 (32bit).
The comments around the assert read:
case VG_TRC_INVARIANT_FAILED:
/* This typically happens if, after running generated code,
it is detected that host CPU settings (eg, FPU/Vector
control words) are not as they should be. Vex's code
generation specifies the state such control words should
be in on entry to Vex-generated code, and they should be
unchanged on exit from it. Failure of this assertion
usually means a bug in Vex's code generation. */
//{ UInt xx;
// __asm__ __volatile__ (
// "\t.word 0xEEF12A10\n" // fmrx r2,fpscr
// "\tmov %0, r2" : "=r"(xx) : : "r2" );
// VG_(printf)(" new fpscr = %08x\n", xx);
//}
vg_assert2(0, "VG_(scheduler), phase 3: "
"run_innerloop detected host "
"state invariant failure", trc);
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 471222] support tracking of file descriptors being double closed
https://bugs.kde.org/show_bug.cgi?id=471222 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Mark Wielaard --- commit 6a28e665f8dd7c031aef5aa0eaa4acbbd8ba27a9 Author: Alexandra Hájková Date: Wed Feb 28 09:02:15 2024 +0100 With --track-fds=yes warn when file descriptor is closed a second time We moved the record_fd_close call from POST to PRE sys_close handler, because the POST handler is only called on success. Even if the close syscall fails the file descriptor is still really closed/invalid. In the PRE handler the file descriptor is about to be closed, but hasn't been yet so we can capture also the description. This patch add new field fd_closed to OpenFd structure to record if the file descriptor was already closed. We now capture a backtrace when closing file descriptors to be able to print it in a case of a double close. Always add '<' brackets '>' around "unbound" in the description for consistency. getsockdetails now takes and returns a buffer describing the socket because we want to record it, not just print it. Note that close_range is handled similar to closing each descriptor individually. But the case when the close_range is called with an infinite end (~0U) is treated special. Add a new record_fd_close_range function which handles close_range with an infinite end so double close by close_range isn't an error because we don't want to loop over such a wide range. Add a new test cases: - none/tests/socket_close.vgtest - tests double closing a socket - none/tests/double_close_range.vgtest - uses close_range to double close the file descriptors - none/tests/file_dclose.vgtest - double closing regular file with regular close syscall https://bugs.kde.org/show_bug.cgi?id=471222 Co-Authored-By: Mark Wielaard -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471222] support tracking of file descriptors being double closed
https://bugs.kde.org/show_bug.cgi?id=471222 --- Comment #17 from Mark Wielaard --- (In reply to Paul Floyd from comment #14) > On second thoughts, isn't the fdleak_ipv4 double close message expected? Yes, it is. It also failed for me locally. I added it to the none/tests/fdleak_ipv4.stderr.exp file. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471222] support tracking of file descriptors being double closed
https://bugs.kde.org/show_bug.cgi?id=471222 --- Comment #16 from Mark Wielaard --- (In reply to Paul Floyd from comment #13) > I had to modify double_close_range.c and socket_close.c like this > > #if defined(__linux__) > #include > #endif > > I get 3 new failures > > The first one has two things. Line number changes because of the Linux > header. close/_close needs filtering. I added that to none/tests/double_close_range.c none/tests/socket_close.c doesn't need it, since it doesn't use any of the constants. I did it so the expected line numbers stay the same (removed two unused headers, added an extra line of whitespace) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471222] support tracking of file descriptors being double closed
https://bugs.kde.org/show_bug.cgi?id=471222 --- Comment #15 from Mark Wielaard --- I needed the following on a system that didn't have close_range: diff --git a/none/tests/Makefile.am b/none/tests/Makefile.am index f56eb7faab67..a37bb27257a6 100644 --- a/none/tests/Makefile.am +++ b/none/tests/Makefile.am @@ -282,8 +282,11 @@ check_PROGRAMS = \ process_vm_readv_writev \ sigprocmask \ socket_close \ - file_dclose \ - double_close_range + file_dclose + +if HAVE_CLOSE_RANGE + check_PROGRAMS += double_close_range +endif if HAVE_NESTED_FUNCTIONS check_PROGRAMS += nestedfns -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 482358] Feature Request: Add --track-fds=error
https://bugs.kde.org/show_bug.cgi?id=482358 --- Comment #2 from Mark Wielaard --- See also https://bugs.kde.org/show_bug.cgi?id=362680 which contains a description how to resurrect CoreErrors (but no patch yet?) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 482358] Feature Request: Add --track-fds=error
https://bugs.kde.org/show_bug.cgi?id=482358 Mark Wielaard changed: What|Removed |Added CC||ahajk...@redhat.com, ||m...@klomp.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471222] support tracking of file descriptors being double closed
https://bugs.kde.org/show_bug.cgi?id=471222 --- Comment #8 from Mark Wielaard --- BTW. In that testcase memcheck/tests/freebsd/close_range.c it has: /* It looks like close_range was initially implemented for FreeBSD 13 * but without CLOSE_RANGE_CLOEXEC * That implementation got back ported to FreeBSD 12.2 * And then CLOSE_RANGE_CLOEXEC added to 13 but not backported * so 12 has close_range but not CLOSE_RANGE_CLOEXEC */ #if !defined(CLOSE_RANGE_CLOEXEC) #define CLOSE_RANGE_CLOEXEC 1 #endif Shouldn't that be 0 instead of 1? Real CLOSE_RANGE_CLOEXEC is 4. What does 1 mean in this case? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471222] support tracking of file descriptors being double closed
https://bugs.kde.org/show_bug.cgi?id=471222 --- Comment #7 from Mark Wielaard --- I forgot about freebsd, sorry. But I see the close_range wrappers are almost identical, so that is good. We can adapt them together. And freebsd already has ./memcheck/tests/freebsd/close_range.vgtest Lets see if we can make that a generic testcase, I see there is already a close_range configure check. I note that freebsd also has a closefrom syscall plus wrapper. But this doesn't seem to implement file descriptor tracking? It should probably use the newly introduced record_fd_close_range. -- You are receiving this mail because: You are watching all bug changes.
