[valgrind] [Bug 69530] we need to implement precise exception handling
https://bugs.kde.org/show_bug.cgi?id=69530 Tom Hughes changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- CC||t...@compton.nu --- Comment #11 from Tom Hughes --- Undoing KDE robot brain damage. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 416682] [MIPS-Linux] mmap failed under valgrind
https://bugs.kde.org/show_bug.cgi?id=416682 --- Comment #4 from Tom Hughes --- In what way is the offset "invalid" and why does it matter whether mmap or mmap2 is used? Are you trying to use some feature that only mmap2 supports? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 416682] [MIPS-Linux] mmap failed under valgrind
https://bugs.kde.org/show_bug.cgi?id=416682 --- Comment #5 from Tom Hughes --- So I can see that both offsets in the strace are the same which isn't what we would expect if your application is calling mmap2 as it should manipulate it differently before passing it to sys_mmap_pgoff. Are you able to capture this map with --trace-syscalls=yes so that we can see what call valgrind is seeing from your application? -- 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 Tom Hughes changed: What|Removed |Added Summary|unhandled instruction |vex amd64->IR: unhandled |bytes: 0xC5 0x79 0xD6 0xED |instruction bytes: 0xC5 |0xC5 0xF9 0x51 |0x79 0xD6 0xED 0xC5 0xF9 ||0x51 CC||t...@compton.nu -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] Missing seccomp support (WARNING: unhandled syscall: 317)
https://bugs.kde.org/show_bug.cgi?id=345414 --- Comment #10 from Tom Hughes --- A third option would be to report success but not actually do anything - that might be necessary for a program which refuses to proceed if it can't install it's seccomp filter but whose filter would break valgrind. The gold plated option of course would be try and modify the filter to allow any system calls valgrind might use in addition to anything which passes the original filter. That would be hard though, even if theoretically possible, and I'm not sure if even that is true. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417906] Please add support for Linux 5.2 CLONE_PIDFD flag to clone()
https://bugs.kde.org/show_bug.cgi?id=417906 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- Do you have a small test case for this? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417906] Please add support for Linux 5.2 CLONE_PIDFD flag to clone()
https://bugs.kde.org/show_bug.cgi?id=417906
--- Comment #3 from Tom Hughes ---
This seems to do the job:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
int pid;
int fd;
if ((pid = syscall(SYS_clone, CLONE_VFORK | CLONE_PIDFD, NULL, &fd, NULL, 0))
< 0)
{
perror("clone");
}
else if (pid > 0)
{
printf("pidfd = %d\n", fd);
waitpid(pid, NULL, 0);
}
exit(0);
}
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 417906] Please add support for Linux 5.2 CLONE_PIDFD flag to clone()
https://bugs.kde.org/show_bug.cgi?id=417906 --- Comment #4 from Tom Hughes --- The problem is not CLONE_PIDFD at all, it's the use of CLONE_VFORK without CLONE_VM. It fails in the same way if you remove CLONE_PIDFD: ==171682== Memcheck, a memory error detector ==171682== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==171682== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==171682== Command: ./clone ==171682== ==171682== Unsupported clone() flags: 0x4000 ==171682== ==171682== The only supported clone() uses are: ==171682== - via a threads library (LinuxThreads or NPTL) ==171682== - via the implementation of fork or vfork ==171682== ==171682== Valgrind detected that your program requires ==171682== the following unimplemented functionality: ==171682==Valgrind does not support general clone(). ==171682== This may be because the functionality is hard to implement, ==171682== or because no reasonable program would behave this way, ==171682== or because nobody has yet needed it. In any case, let us know at ==171682== www.valgrind.org and/or try to work around the problem, if you can. ==171682== ==171682== Valgrind has to exit now. Sorry. Bye! ==171682== We only support three basic modes of operation, defined by the values of the following flags: * CLONE_VM * CLONE_FS * CLONE_FILES * CLONE_VFORK Those modes are: * thread creation (CLONE_VM, CLONE_FS and CLONE_FILES set) * traditional vfork (CLONE_VFORK and CLONE_VM set) * traditional fork (none of the above set) We generally allow any combination of other flags however, it's just those four that are required to choose which general mode of operation we are dealing with. Setting CLONE_VFORK on it's own has the effect of causing the parent to be suspended until the child exits or execs but without the shared address space that vfork would normally have. That makes it closer to fork than vfork really and in any case valgrind transforms vfork to fork by removing the CLONE_VM flag so I see no reason not to allow this combination. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417906] clone with CLONE_VFORK and no CLONE_VM fails
https://bugs.kde.org/show_bug.cgi?id=417906 Tom Hughes changed: What|Removed |Added Summary|Please add support for |clone with CLONE_VFORK and |Linux 5.2 CLONE_PIDFD flag |no CLONE_VM fails |to clone() | -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417906] clone with CLONE_VFORK and no CLONE_VM fails
https://bugs.kde.org/show_bug.cgi?id=417906 Tom Hughes changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #5 from Tom Hughes --- Fixed in 3e11902ce28ff43cff679bf2453c597d568fde8f with a followup in 22aa8640e6c44c78c228ffa726cfacf918455343 to mark the returned descriptor as defined with CLONE_PIDFD is used. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 409501] amd64->IR: unhandled instruction bytes
https://bugs.kde.org/show_bug.cgi?id=409501 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #5 from Tom Hughes --- Because nobody has provided a patch to implement it? Perhaps you are under the belief that we have a full time team of programmers paid to read each new architecture and immediately implement all the new instructions? I'm afraid that is not how it works. The simple answer is that commonly used instructions are always going to be the first to get implemented when only limited resources are available, and instructions specific to a minority processor brand are less likely to get done because most people build code to target a broad range of processors so will never encounter such instructions. Of course if somebody offers a high quality patch to implement them then I'm sure it would be gratefully accepted. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 409999] vex amd64->IR: unhandled instruction bytes: 0x62 0xD1 0xFE 0x8 0x6F 0x84 0x24 0x8 0x0 0x0
https://bugs.kde.org/show_bug.cgi?id=40 Tom Hughes changed: What|Removed |Added Summary|Valgrind causes SIGILL due |vex amd64->IR: unhandled |to unrecognized instruction |instruction bytes: 0x62 |in rocksdb static |0xD1 0xFE 0x8 0x6F 0x84 |initialization |0x24 0x8 0x0 0x0 CC||t...@compton.nu -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 409999] vex amd64->IR: unhandled instruction bytes: 0x62 0xD1 0xFE 0x8 0x6F 0x84 0x24 0x8 0x0 0x0
https://bugs.kde.org/show_bug.cgi?id=40 --- Comment #1 from Tom Hughes --- In 32 bit mode 0x62 would be BOUND which would win some sort of obscurity contest, but in 64 bit mode it doesn't appear to be valid and as far as I can see it hasn't been replaced by anything else, at least in the version of the Intel manual I am looking at... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 409999] vex amd64->IR: unhandled instruction bytes: 0x62 0xD1 0xFE 0x8 0x6F 0x84 0x24 0x8 0x0 0x0
https://bugs.kde.org/show_bug.cgi?id=40 --- Comment #2 from Tom Hughes --- The latest (May 2019) edition seems to agree. Did you compile this yourself, and if you did what architecture did you target exactly? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 356715] vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0x13 0x4 0x4A 0xC5 0xFC
https://bugs.kde.org/show_bug.cgi?id=356715 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #4 from Tom Hughes --- Please don't hijack unrelated bugs - every unsupported instruction is different and the one you quote has an entirely different byte stream to this one. Your byte stream looks like it matches bug https://bugs.kde.org/show_bug.cgi?id=40 so that is the place to discuss it. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 191062] unhandled instruction bytes: 0xF 0xB 0x78 0x65
https://bugs.kde.org/show_bug.cgi?id=191062 Tom Hughes changed: What|Removed |Added CC||memec...@gmail.com --- Comment #4 from Tom Hughes --- *** Bug 410562 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410562] Unrecognised instruction 'UD2'
https://bugs.kde.org/show_bug.cgi?id=410562 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED CC||t...@compton.nu Resolution|--- |DUPLICATE --- Comment #1 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 191062 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 398086] Unrecognised instruction with X11 + OpenGL programs
https://bugs.kde.org/show_bug.cgi?id=398086 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #7 from Tom Hughes --- There is a similar example in https://bugs.kde.org/show_bug.cgi?id=410562 of a _dispatch_kq routine hitting an undefined instruction which is confirmed there as ud2. I won't close this as dupe as it has a second issue but https://bugs.kde.org/show_bug.cgi?id=191062 is the main ud2 bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410562] Unrecognised instruction 'UD2'
https://bugs.kde.org/show_bug.cgi?id=410562 Tom Hughes changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|DUPLICATE |--- --- Comment #2 from Tom Hughes --- Actually I don't think closing this as dupe is a good idea because I suspect hitting ud2 is just a result of it trying to abort - the real problem here is not understanding how to deal with the mach message. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410764] BLENDVPD, BLENDVPS, PBLENDVB not implemented in guest_x86
https://bugs.kde.org/show_bug.cgi?id=410764 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Our general policy is that new opcodes are only added to the 64 bit backend. The 32 bit backend is very old and is hard to extend further without a lot of work while the 64 bit backend has been extensively rewritten to better support decoding the large number of new opcodes that have been added. Further information is available at http://valgrind.org/docs/manual/manual-core.html#manual-core.limits but broadly speaking 32 bit support is frozen at SSSE3 level, plus a few SSE4 instructions needed to be able to run 32 bit programs on MacOS. The cpuid we report in 32 bit mode should correctly identify what opcodes we support there. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414053] vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFE 0x8 0x6F 0x45 0x0 0xC5 0xF8 0x11
https://bugs.kde.org/show_bug.cgi?id=414053 Tom Hughes changed: What|Removed |Added Summary|vex amd64->IR: unhandled|vex amd64->IR: unhandled |instruction bytes |instruction bytes: 0x62 ||0xF1 0xFE 0x8 0x6F 0x45 0x0 ||0xC5 0xF8 0x11 CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Here's the actual detail extracted from the attached log: vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFE 0x8 0x6F 0x45 0x0 0xC5 0xF8 0x11 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==35078== valgrind: Unrecognised instruction at address 0x4a50820. ==35078==at 0x4A50820: H5P_dup_prop (in /usr/lib64/libhdf5.so.103.1.0) ==35078==by 0x4A52465: H5P__do_prop_cb1.part.13 (in /usr/lib64/libhdf5.so.103.1.0) ==35078==by 0x4A51C01: H5P_create_id (in /usr/lib64/libhdf5.so.103.1.0) ==35078==by 0x4A52155: H5P__init_package (in /usr/lib64/libhdf5.so.103.1.0) ==35078==by 0x4A522C7: H5P_init (in /usr/lib64/libhdf5.so.103.1.0) ==35078==by 0x48C60ED: H5_init_library (in /usr/lib64/libhdf5.so.103.1.0) ==35078==by 0x48C690F: H5open (in /usr/lib64/libhdf5.so.103.1.0) ==35078==by 0x1091C8: main (h5simple.cpp:6) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414291] https://valgrind.org has an invalid certificate
https://bugs.kde.org/show_bug.cgi?id=414291 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Where did you see that URL advertised? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414291] https://valgrind.org has an invalid certificate
https://bugs.kde.org/show_bug.cgi?id=414291 Tom Hughes changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #4 from Tom Hughes --- Well that is what I suspect and was kind of my point - it is not valid to assume that you can just replace http with https. When a site has not been https enabled and you try that you are going to get an error, whether a mismatch like this because you get a certificate for a different site on the same machine or a self signed certificate or just a connection failure. It's fixed now anyway, and valgrind.org is improved by being https enabled which is a good outcome. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 411303] vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7E 0x28 0x7F 0x5 0xC6 0xEA 0x12 0x0
https://bugs.kde.org/show_bug.cgi?id=411303 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Summary|Illegal hardware|vex amd64->IR: unhandled |instruction when using |instruction bytes: 0x62 |memcheck on lepton |0xF1 0x7E 0x28 0x7F 0x5 ||0xC6 0xEA 0x12 0x0 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 394582] vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7C 0x48 0x57 0xC0 0x48 0x8D 0x35 0x6A
https://bugs.kde.org/show_bug.cgi?id=394582 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED CC||t...@compton.nu --- Comment #1 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 393351 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 411303] vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7E 0x28 0x7F 0x5 0xC6 0xEA 0x12 0x0
https://bugs.kde.org/show_bug.cgi?id=411303 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 393351 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 Tom Hughes changed: What|Removed |Added CC||wmzhao.c...@gmail.com --- Comment #3 from Tom Hughes --- *** Bug 394582 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 Tom Hughes changed: What|Removed |Added CC||wang8...@umn.edu --- Comment #4 from Tom Hughes --- *** Bug 411303 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 Tom Hughes changed: What|Removed |Added CC||andrei...@gmail.com --- Comment #5 from Tom Hughes --- *** Bug 40 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 409999] vex amd64->IR: unhandled instruction bytes: 0x62 0xD1 0xFE 0x8 0x6F 0x84 0x24 0x8 0x0 0x0
https://bugs.kde.org/show_bug.cgi?id=40 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #4 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 393351 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #6 from Tom Hughes --- As I said on 393351 according to the Intel manual 0x62 is BOUND but that is not valid in 64 bit mode. As far as I can see in the latest manual it hasn't been reused for anything else so this is very odd indeed... A disassembly of something that is triggering this would probably be helpful. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #7 from Tom Hughes --- Sorry I mean on https://bugs.kde.org/show_bug.cgi?id=40... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414659] Unrecognised instruction /opt/wine-devel/lib64/wine/ntdll.dll.so
https://bugs.kde.org/show_bug.cgi?id=414659 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #4 from Tom Hughes --- Please give us the full error - valgrind should have reported what instruction it couldn't decode in detail before the stack trace. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414659] vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
https://bugs.kde.org/show_bug.cgi?id=414659 Tom Hughes changed: What|Removed |Added Summary|Unrecognised instruction|vex amd64->IR: unhandled |/opt/wine-devel/lib64/wine/ |instruction bytes: 0x48 |ntdll.dll.so|0xCF 0xF 0x1F 0x0 0xFF 0xD2 ||0xCC 0x90 0x55 --- Comment #7 from Tom Hughes --- Sorry I missed that. Here are the important details: vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 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=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==21781== valgrind: Unrecognised instruction at address 0x7bcb6b83. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414659] vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
https://bugs.kde.org/show_bug.cgi?id=414659 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #8 from Tom Hughes --- So that is IRET which is not currently supported in 64 bit mode. We already have a bug covering this so I'm going to close this as a duplicate. *** This bug has been marked as a duplicate of bug 253657 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 Tom Hughes changed: What|Removed |Added CC||eekn...@gmail.com --- Comment #26 from Tom Hughes --- *** Bug 414659 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 400538] vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
https://bugs.kde.org/show_bug.cgi?id=400538 Tom Hughes changed: What|Removed |Added CC||eekn...@gmail.com --- Comment #13 from Tom Hughes --- *** Bug 414659 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414659] vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
https://bugs.kde.org/show_bug.cgi?id=414659 --- Comment #10 from Tom Hughes --- Ah I had a feeling it has been fixed recently but I missed that. The user here is running 3.13 so won't have the fix but I'll update the duplicate. *** This bug has been marked as a duplicate of bug 400538 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414870] std::frexp(long double) broken under valgrind.
https://bugs.kde.org/show_bug.cgi?id=414870 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Please see http://valgrind.org/docs/manual/manual-core.html#manual-core.limits for details of limitations on valgrind's floating point support. In particular please note that there is no support for x86-32 80 bit floating point. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414870] std::frexp(long double) broken under valgrind.
https://bugs.kde.org/show_bug.cgi?id=414870 --- Comment #3 from Tom Hughes --- Well sure gcc may have generated different code. The point is that once you use long double on x86-32 there is no guarantee you will get the same results under valgrind as when running natively. You might, but you might not. Actually that can be true even with double because gcc by default generates code that can keep values on the x87 stack between operations, so 80 bit precision is used until gcc needs to move the value back to memory. Using -ffloat-store can reduce that by forcing it to move stuff back to memory more often, or just use -mfpmath=sse to make it use SSE for floating point where you will get standard IEEE semantics. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414944] vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7D 0x48 0xEF 0xC0 0x48 0x8D 0x7D 0xD0
https://bugs.kde.org/show_bug.cgi?id=414944 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 393351 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414053] vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFE 0x8 0x6F 0x45 0x0 0xC5 0xF8 0x11
https://bugs.kde.org/show_bug.cgi?id=414053 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 393351 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 Tom Hughes changed: What|Removed |Added CC||jody@gmail.com --- Comment #8 from Tom Hughes --- *** Bug 414053 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 Tom Hughes changed: What|Removed |Added CC||caiyueq...@bytedance.com --- Comment #9 from Tom Hughes --- *** Bug 414944 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414944] vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7D 0x48 0xEF 0xC0 0x48 0x8D 0x7D 0xD0
https://bugs.kde.org/show_bug.cgi?id=414944 --- Comment #3 from Tom Hughes --- Right but 0x62 is a single byte instruction so only the first byte matters... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #12 from Tom Hughes --- Can you please try and disassemble the problem function - this should do it I think: objdump --disassemble=_ZN7rocksdb27AdvancedColumnFamilyOptionsC2Ev /root/open_source/rocksdb/build/librocksdb.so.6.6.0 Then post the output here? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 415159] DHAT doesn't output anything when running the rust compiler
https://bugs.kde.org/show_bug.cgi?id=415159 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- That looks like you ran valgrind on cargo rather than on the compiler? or does the compiler run as part of cargo? Does tracing into children with --trace-children=yes help? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 415159] DHAT doesn't output anything when running the rust compiler
https://bugs.kde.org/show_bug.cgi?id=415159 --- Comment #3 from Tom Hughes --- Well yes they will all spin off children because rustc is a separate program to cargo - it's like tracing make and it not following over the exec when it runs gcc to do the actual compile. Note that --trace-children is slightly misnamed because it doesn't control tracing over fork (fork is always followed) but rather it controls whether an exec of a new executable is followed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 415382] vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x79 0x13 0x14 0x1A 0xC5 0xF9 0x6E 0xE9
https://bugs.kde.org/show_bug.cgi?id=415382 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- I believe this is vcvtph2ps (opcode 0x0f 0x38 0x13 with 0x66 prefix). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 415382] vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x79 0x13 0x14 0x1A 0xC5 0xF9 0x6E 0xE9
https://bugs.kde.org/show_bug.cgi?id=415382 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #3 from Tom Hughes --- This is already fixed in 3.15.0 by the looks of it. *** This bug has been marked as a duplicate of bug 398870 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 398870] Please add support for instruction vcvtps2ph
https://bugs.kde.org/show_bug.cgi?id=398870 Tom Hughes changed: What|Removed |Added CC||the.true.nathan.mills@gmail ||.com --- Comment #1 from Tom Hughes --- *** Bug 415382 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 398870] Please add support for instruction vcvtps2ph
https://bugs.kde.org/show_bug.cgi?id=398870 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED CC||t...@compton.nu --- Comment #2 from Tom Hughes --- This was fixed in the 3.15.0 release. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 356715] vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0x13 0x4 0x4A 0xC5 0xFC
https://bugs.kde.org/show_bug.cgi?id=356715 --- Comment #5 from Tom Hughes --- This is VCVTPH2PS and is fixed in the 3.15.0 release. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 415382] vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x79 0x13 0x14 0x1A 0xC5 0xF9 0x6E 0xE9
https://bugs.kde.org/show_bug.cgi?id=415382 --- Comment #4 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 356715 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 356715] vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0x13 0x4 0x4A 0xC5 0xFC
https://bugs.kde.org/show_bug.cgi?id=356715 Tom Hughes changed: What|Removed |Added CC||the.true.nathan.mills@gmail ||.com --- Comment #6 from Tom Hughes --- *** Bug 415382 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 448991] leak on fedora 33 and higher in getaddrinfo
https://bugs.kde.org/show_bug.cgi?id=448991 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG CC||t...@compton.nu --- Comment #1 from Tom Hughes --- That's not a leak - as valgrind says that memory is still reachable. A leak is memory is unreachable because there are no pointers to it but it hasn't been freed. What you're looking at is some sort of cache inside the dynamic linker. Possibly it's a glibc bug, in that we deliberately call __libc_freeres to ask glibc to free it's internal resources at exit (which doesn't happen normally) but it's not a valgrind bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 405377] Handle new Linux kernel feature: Restartable Sequences ("rseq")
https://bugs.kde.org/show_bug.cgi?id=405377 Tom Hughes changed: What|Removed |Added CC||m...@linux.ibm.com --- Comment #6 from Tom Hughes --- *** Bug 449199 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 449199] unhandled syscall 387 on ppc64le-linux
https://bugs.kde.org/show_bug.cgi?id=449199 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE CC||t...@compton.nu Status|REPORTED|RESOLVED --- Comment #1 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 405377 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 455279] vex amd64->IR: unhandled instruction bytes: 0x62 0xD2 0xFD 0x28 0x7C 0xC8 0x62 0xF2 0xFD 0x28
https://bugs.kde.org/show_bug.cgi?id=455279 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Well 0x62 is a BOUND instruction, or it would be in 32 bit mode, but it's not valid in 64 bit mode. Did you get any warnings from valgrind before that about referencing undefined values? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 455279] vex amd64->IR: unhandled instruction bytes: 0x62 0xD2 0xFD 0x28 0x7C 0xC8 0x62 0xF2 0xFD 0x28
https://bugs.kde.org/show_bug.cgi?id=455279 --- Comment #2 from Tom Hughes --- Ah it's an EVEX prefix now but the opcode map in the Intel manual helpfully doesn't mention that... There is no AVX512 support in valgrind currently so you can't run code that is compiled to use AVX512 instructions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 408140] Missing support for vmovdqu64
https://bugs.kde.org/show_bug.cgi?id=408140 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED CC||t...@compton.nu --- Comment #2 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 383010 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383010] Add support for AVX-512 instructions
https://bugs.kde.org/show_bug.cgi?id=383010 Tom Hughes changed: What|Removed |Added CC||arkang...@gmail.com --- Comment #76 from Tom Hughes --- *** Bug 408140 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 455279] vex amd64->IR: unhandled instruction bytes: 0x62 0xD2 0xFD 0x28 0x7C 0xC8 0x62 0xF2 0xFD 0x28
https://bugs.kde.org/show_bug.cgi?id=455279 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #3 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 383010 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383010] Add support for AVX-512 instructions
https://bugs.kde.org/show_bug.cgi?id=383010 Tom Hughes changed: What|Removed |Added CC||fchen0...@gmail.com --- Comment #77 from Tom Hughes --- *** Bug 455279 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383010] Add support for AVX-512 instructions
https://bugs.kde.org/show_bug.cgi?id=383010 Tom Hughes changed: What|Removed |Added CC||ytr...@sdf-eu.org --- Comment #78 from Tom Hughes --- *** Bug 451837 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451837] When profiling this specific executable, valgrind fails to break down 0x62 0xF1 0x7F 0x28 0x7F 0x2 0xF 0x87 0x95 0xA1 into 2 separate instructions
https://bugs.kde.org/show_bug.cgi?id=451837 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #7 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 383010 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 455740] Tip to improve "a function redirection which is mandatory..." error message
https://bugs.kde.org/show_bug.cgi?id=455740 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Well that is not information that is generally known to us, and it can vary from release to release even within a distribution never mind having to cover many different distributions - the text would probably get out of hand pretty quickly I fear even if it was possible for us to gather the necessary information. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 455740] Tip to improve "a function redirection which is mandatory..." error message
https://bugs.kde.org/show_bug.cgi?id=455740 --- Comment #2 from Tom Hughes --- Also I don't see why installing debuginfod would help - installing the client tools might help but there's no reason you should need the daemon. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 455740] Include hints for Arch linux in error message for missing rediretions
https://bugs.kde.org/show_bug.cgi?id=455740 Tom Hughes changed: What|Removed |Added Summary|Tip to improve "a function |Include hints for Arch |redirection which is|linux in error message for |mandatory..." error message |missing rediretions -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 455740] Include hints for Arch linux in error message for missing redirections
https://bugs.kde.org/show_bug.cgi?id=455740 Tom Hughes changed: What|Removed |Added Summary|Include hints for Arch |Include hints for Arch |linux in error message for |linux in error message for |missing rediretions |missing redirections -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 455740] Include hints for Arch linux in error message for missing redirections
https://bugs.kde.org/show_bug.cgi?id=455740 --- Comment #4 from Tom Hughes --- I hadn't initially understood that you were suggesting an addition to an existing message because the way the initial parts of the report made it written made it sound like this was a new idea to document hints for distributions rather than just requesting to add an extra distribution. I'm sure installing debuginfod did help but probably because it dragged in a dependent package that provided the debuginfod-find command (which is what valgrind uses to find debuginfo automatically) which was my point. On Fedora for example you could install elfutils-debuginfod-client instead of actually installing the debuginfo package, but you wouldn't need elfutils-debuginfod which is the actual daemon. Maybe Arch puts it all in one package though? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 480042] False-positive "uninitialised value" with GStreamer and ffmpeg
https://bugs.kde.org/show_bug.cgi?id=480042 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- Arguably it's a genuine bug anyway - you're leaking unknown data into that file which could include anything which has previously been store in a malloced block in your program and might include sensitive data of various sorts. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 480545] unhandled instruction bytes: 0x62 0xF1 0xFE 0x48 0x7F 0x84 0x24 0x10 0x0 0x0
https://bugs.kde.org/show_bug.cgi?id=480545 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE CC||t...@compton.nu Status|REPORTED|RESOLVED --- Comment #1 from Tom Hughes --- That's an EVEX prefix, so this is AVX-512 or at least an AVX-512 related encoding. *** This bug has been marked as a duplicate of bug 383010 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383010] Add support for AVX-512 instructions
https://bugs.kde.org/show_bug.cgi?id=383010 Tom Hughes changed: What|Removed |Added CC||k...@chrisada.co.uk --- Comment #93 from Tom Hughes --- *** Bug 480545 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 480680] vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0x74 0x26
https://bugs.kde.org/show_bug.cgi?id=480680 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #1 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 478624 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 478624] Valgrind incompatibility with binutils-2.42 on x86 with new nop patterns (unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26)
https://bugs.kde.org/show_bug.cgi?id=478624 Tom Hughes changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #4 from Tom Hughes --- *** Bug 480680 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 480680] vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0x74 0x26
https://bugs.kde.org/show_bug.cgi?id=480680 --- Comment #2 from Tom Hughes --- I know it's not exactly the same instruction but d35005cef8ad8207542738812705ceabf137d7e0 that fixed that other bug should cover this case as well. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 162229] VALGRIND_DO_LEAK_CHECK emits false positive
https://bugs.kde.org/show_bug.cgi?id=162229 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #6 from Tom Hughes --- No I don't think it's anything to do with word boundaries, rather I suspect it's actually everything working as expected. What "possibly lost" means is that valgrind didn't find a pointer to the start of the allocated block but did find a pointer to an address inside the block. That is of course exactly what is happening here - inside std::string it is storing a pointer to the actual string data but that isn't the start of the block it allocated because it has stashed some metadata before the string data. I assume it's doing something like storing the length before the start of the string data? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 457860] Memcheck classifies leaks differently depending on if a C program exits with `return` or `exit`
https://bugs.kde.org/show_bug.cgi?id=457860 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- This is because when you return the stack frame for main is discarded and "a" is no longer live but when you call exit that stack frame still exists and "a" is still live as a result. I think it would be quite hard for valgrind to figure out that exit had been called and then where to unwind the stack to which is what would be needed to get the two to behave the same. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 459047] Incorrect memory leak report
https://bugs.kde.org/show_bug.cgi?id=459047 Tom Hughes changed: What|Removed |Added Summary|Memory leak in valgrind |Incorrect memory leak |memcheck code |report CC||t...@compton.nu Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #3 from Tom Hughes --- I'm not sure why you call this a memory leak in valgrind - it's valgrind reporting a memory leak in your program. It's also completely correct - you allocate two arrays but only free one. You allocate an array of double in main, which you assign to testarray, and that allocation is never freed. You also allocate an array of pointers to double in divide2DDoubleArray which you return to main via the subblockdividers reference parameter where is is storeed in pTestarray. You then free pTestarray, but that is an array of raw pointers so freeing it has no effect on the pointers it contains and they remain allocated, so the fact that the first one points to testarray does not mean testarray gets freed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 459047] Incorrect memory leak report
https://bugs.kde.org/show_bug.cgi?id=459047 Tom Hughes changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #5 from Tom Hughes --- You misunderstand - the "unsigned long" there is not the type of the array, it's the argument to operator new, which is just the number of bytes to allocate and is always unsigned long (well std::size_t but apparently that is equivalent to unsigned long on your platform). See https://en.cppreference.com/w/cpp/memory/new/operator_new which lists the various versions of operator new - in this case it is the second one that was called to do the allocation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 459047] Incorrect memory leak report
https://bugs.kde.org/show_bug.cgi?id=459047 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #7 from Tom Hughes --- Will you please stop reopening this bug. This is not a bug. There is no problem in valgrind disclosed here. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470244] mremap() call not fully implemented and when attempting to resize the same address to a larger size the mremap() call responded with MAP_FAILED.
https://bugs.kde.org/show_bug.cgi?id=470244 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Disabling mmap support would render valgrind useless - if it doesn't know what memory has been allocated that it can't track it's state. Any program has to assume that memory allocations may fail and deal with that so technically I'm not sure this is really a bug - the behaviour of memory allocation under valgrind is often very different to when running normally simply because it has to allocate extra memory to track state and that is all happening in the same address space. We certainly don't reject all mremap's that expand out of hand, as you can see at https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_syswrap/syswrap-generic.c;h=efdae60e10320cbcccd86415fabf6ef8fd7abf57;hb=HEAD#l275 which is the current implementation. A starting point would probably be to run with --trace-syscalls=yes so we can see exactly what arguments are being passed and trace out what path it is following in that handler. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470244] mremap() call not fully implemented and when attempting to resize the same address to a larger size the mremap() call responded with MAP_FAILED.
https://bugs.kde.org/show_bug.cgi?id=470244 --- Comment #5 from Tom Hughes --- This is the call: SYSCALL[157805,1](25) sys_mremap ( 0xac, 8192, 16384, 0x0 ) --> [pre-fail] Failure(0xc) so it's being rejected by valgrind with ENOMEM without being passed to the kernel. Given the flags we are reaching grow_in_place_or_fail (https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_syswrap/syswrap-generic.c;h=efdae60e10320cbcccd86415fabf6ef8fd7abf57;hb=HEAD#l479) and that is rejecting it most likely because VG_(am_get_advisory_client_simple) says that extra memory is not available for some reason. To find out why would probably need a custom build with the "if (0)" near the top of VG_(am_get_advisory) enabled so that it dumps the memory map which would show if something else was already allocated there. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470244] mremap() call not fully implemented and when attempting to resize the same address to a larger size the mremap() call responded with MAP_FAILED.
https://bugs.kde.org/show_bug.cgi?id=470244 --- Comment #9 from Tom Hughes --- Actually I can see the problem there - the following segment is an SkResvn not SkFree. Now VG_(am_get_advisory_client_simple) will allow a reservation to be used so will accept the request, but VG_(am_covered_by_single_free_segment) will then reject it as it only allows a free segment. If we got past that then VG_(am_extend_map_client) would assert for the same reason... I'm not really sure about the difference between the two but my reading is that reservations are unused they're just in the top part of memory. I think the idea is to discourage allocations there so that valgrind can use it for shadow memory but still allow it if the caller insists by asking for a fixed address. Try this patch and see if it helps: --- a/coregrind/m_aspacemgr/aspacemgr-linux.c +++ b/coregrind/m_aspacemgr/aspacemgr-linux.c @@ -2213,7 +2213,7 @@ static NSegment const * VG_(am_find_free_nsegment) ( Addr a ) aspacem_assert(i >= 0 && i < nsegments_used); aspacem_assert(nsegments[i].start <= a); aspacem_assert(a <= nsegments[i].end); - if (nsegments[i].kind == SkFree) + if (nsegments[i].kind == SkFree || nsegments[i].kind == SkResvn) return &nsegments[i]; else return NULL; @@ -3203,7 +3203,7 @@ const NSegment *VG_(am_extend_map_client)( Addr addr, SizeT delta ) /* The segment following the client segment must be a free segment and it must be large enough to cover the additional memory. */ NSegment *segf = seg + 1; - aspacem_assert(segf->kind == SkFree); + aspacem_assert(segf->kind == SkFree || segf->kind == SkResvn); aspacem_assert(segf->start == xStart); -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470244] mremap() call not fully implemented and when attempting to resize the same address to a larger size the mremap() call responded with MAP_FAILED.
https://bugs.kde.org/show_bug.cgi?id=470244 Tom Hughes changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from Tom Hughes --- Let's leave it open for now until that is upstream. As I say I'm not 100% sure about free vs resvn and whether that patch is completely correct so I'll try and find out before I think about committing it... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470489] vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 0xFD 0x28 0x7C 0xE0 0x48 0x8D 0x90 0x0
https://bugs.kde.org/show_bug.cgi?id=470489 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED CC||t...@compton.nu Resolution|--- |DUPLICATE --- Comment #1 from Tom Hughes --- That's an AVX-512 instruction, or an EVEX prefix at least which amount to the same thing from our point of view. *** This bug has been marked as a duplicate of bug 383010 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383010] Add support for AVX-512 instructions
https://bugs.kde.org/show_bug.cgi?id=383010 Tom Hughes changed: What|Removed |Added CC||toitran4...@gmail.com --- Comment #92 from Tom Hughes --- *** Bug 470489 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470978] s390x: Valgrind cannot start qemu-kvm when "sysctl vm.allocate_pgste=0"
https://bugs.kde.org/show_bug.cgi?id=470978 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Does the kernel provide an API to allow user space to activate this? If it doesn't then there isn't much valgrind can do, other than provide an option to add that ELF section to the valgrind binary, which would then mean all valgrind use would have it activated. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 456948] Unrecognized instruction CLFLUSHOPT in Intel oneAPI MPI 2021.6 library
https://bugs.kde.org/show_bug.cgi?id=456948 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #7 from Tom Hughes --- No instructions are "forbidden" but some are not supported yet. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 456948] Unrecognized instruction CLFLUSHOPT in Intel oneAPI MPI 2021.6 library
https://bugs.kde.org/show_bug.cgi?id=456948 --- Comment #11 from Tom Hughes --- That is exactly what we do and why Mark said your program should be checking the CPU capabilities. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432440] Valgrind always crashes Rust programs on FreeBSD with "failed to allocate a guard page"
https://bugs.kde.org/show_bug.cgi?id=432440 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DOWNSTREAM CC||t...@compton.nu --- Comment #1 from Tom Hughes --- The FreeBSD port of valgrind is currently a separate fork that is not maintained as part of the core project. You can find an issue tracker for it at https://github.com/paulfloyd/freebsd_valgrind/issues. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432440] Valgrind always crashes Rust programs on FreeBSD with "failed to allocate a guard page"
https://bugs.kde.org/show_bug.cgi?id=432440 --- Comment #3 from Tom Hughes --- That error won't be anything to do with the code as such though, it will be to do with the OS integration and how the system calls and memory management are emulated and the details of that will likely vary even among different BSD derived platforms. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432508] Valgrind does not honor setrlimit RLIMIT_NOFILE changes
https://bugs.kde.org/show_bug.cgi?id=432508 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Because valgrind has to reserve some file descriptors for it's own use at the top of the range it is not able to honour all requests to increase limits. What were the soft and hard limits when your program started? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432508] Valgrind does not honor setrlimit RLIMIT_NOFILE changes
https://bugs.kde.org/show_bug.cgi?id=432508 --- Comment #3 from Tom Hughes --- Right to basically what valgrind does is that it increases the soft limit by the number of descriptors it wants to reserve for itself, and then lowers the emulated soft and hard limits to the soft limit. So you should find that your first getrlimit actually reports a hard limit of 1024 as well as a soft limit of 1024 and that your setrlimit fails. So basically this is one place where the emulated environment is not quite the same as the host environment, but if you pay attention to system call results you should get results which match the emulated environment. If you need more descriptors when running under valgrind then you will need to raise the soft limit before starting it. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- I reproduced this - it's the value of hp that valgrind thinks is uninitialised after the loop computing it. Altering the loop in any way seems to stop it happening. I didn't look at the assembly in any detail but I think clang is folding that loop that adds up a constant char array into some "clever" calculation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433272] vex amd64->IR: unhandled instruction bytes: 0x62 0x91 0x7F 0x28 0x6F 0x4 0x3 0x62 0x91 0x7F
https://bugs.kde.org/show_bug.cgi?id=433272 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Summary|Boost iostreams|vex amd64->IR: unhandled |mapped_file causes |instruction bytes: 0x62 |unrecognised instruction|0x91 0x7F 0x28 0x6F 0x4 0x3 ||0x62 0x91 0x7F -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433272] vex amd64->IR: unhandled instruction bytes: 0x62 0x91 0x7F 0x28 0x6F 0x4 0x3 0x62 0x91 0x7F
https://bugs.kde.org/show_bug.cgi?id=433272 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #1 from Tom Hughes --- That's an AVX512 instruction and those aren't supported yet. It's not actually the boost code that's the issue by the way, it's actually the mempcpy replacement routine in valgrind so valgrind must have been compiled with -march=native or some other option that enabled avx512 support. *** This bug has been marked as a duplicate of bug 383010 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383010] Add support for AVX-512 instructions
https://bugs.kde.org/show_bug.cgi?id=383010 Tom Hughes changed: What|Removed |Added CC||qoman...@gmail.com --- Comment #46 from Tom Hughes --- *** Bug 433272 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433323] Use pkglibexecdir as vglibdir
https://bugs.kde.org/show_bug.cgi?id=433323 --- Comment #2 from Tom Hughes --- Note that libexec usage varies quite a bit across distros - it's not used much on Ubuntu for example but is on Fedora. Bizarrely valgrind is one of the few packages that does seem to use libexec on Ubuntu, but only for the DHAT html/js/css files, which seems very odd. -- You are receiving this mail because: You are watching all bug changes.
