[valgrind] [Bug 483372] Double calloc() not detected
https://bugs.kde.org/show_bug.cgi?id=483372 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #1 from Tom Hughes --- It has been detected - that's what the leak report is. The call to another_function changed the value of var_one causing the original value to be leaked, and that leak was correctly reported by valgrind. The free call then frees the block which var_one now points to, which is the second allocated done by another_function, so there is no problem to report with that block. -- 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 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 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 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 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 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 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 476662] vex amd64->IR: unhandled instruction bytes: 0x66 0x9D (popf)
https://bugs.kde.org/show_bug.cgi?id=476662 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Summary|Popfw causes crash |vex amd64->IR: unhandled ||instruction bytes: 0x66 ||0x9D (popf) -- 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 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 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 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 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 [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 --- 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 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 469878] unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x44 0x24 0x1 0x83 0xE7
https://bugs.kde.org/show_bug.cgi?id=469878 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #2 from Tom Hughes --- That's an AVX-512 instruction. *** 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||tus...@kazv.moe --- Comment #91 from Tom Hughes --- *** Bug 469878 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469565] valgrind not detecting simple leak with malloc(In Arm System)
https://bugs.kde.org/show_bug.cgi?id=469565 --- Comment #6 from Tom Hughes --- It shouldn't be possible to strip libc.so in a way that removes a public symbol like malloc - it must at least be in the dynamic symbol table or the dynamic linker couldn't work. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469565] valgrind not detecting simple leak with malloc(In Arm System)
https://bugs.kde.org/show_bug.cgi?id=469565 --- Comment #4 from Tom Hughes --- Are using a statically linked C library? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469565] valgrind not detecting simple leak with malloc(In Arm System)
https://bugs.kde.org/show_bug.cgi?id=469565 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- This is the root cause: ==1581== total heap usage: 0 allocs, 0 frees, 0 bytes allocated The malloc and free calls are not being intercepted for some reason. -- 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 --- Comment #5 from Tom Hughes --- I believe the instruction is: VEX.128.66.0F.WIG D6 /r VMOVQ xmm1/m64, xmm2 Move quadword from xmm2 register to xmm1/m64. -- 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 Ever confirmed|0 |1 Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED --- Comment #4 from Tom Hughes --- Scratch that I'm talking nonsense - that is VEX encoding. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339416] unhandled instruction bytes 0xC5 0xF1 0xEF 0xC9 [AVX]
https://bugs.kde.org/show_bug.cgi?id=339416 Tom Hughes changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #2 from Tom Hughes --- Scratch that I'm talking nonsense - that is VEX encoding. -- 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 --- Comment #90 from Tom Hughes --- *** Bug 339416 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339416] unhandled instruction bytes 0xC5 0xF1 0xEF 0xC9 [AVX]
https://bugs.kde.org/show_bug.cgi?id=339416 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE CC||t...@compton.nu --- Comment #1 from Tom Hughes --- That is an AVX512 instruction, or at least uses EVEX encoding, which means it is dependent on AVX512 support being added. *** 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||arnaud.desit...@gmail.com --- Comment #89 from Tom Hughes --- *** Bug 417572 has been marked as a duplicate of this bug. *** -- 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 Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #3 from Tom Hughes --- That is an AVX512 instruction, or at least uses EVEX encoding, which means it is dependent on AVX512 support being added. Until then you will need to compile to target an architecture that does not support AVX512. *** 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 425445] memcheck cannot display the error line number
https://bugs.kde.org/show_bug.cgi?id=425445 Tom Hughes changed: What|Removed |Added Ever confirmed|0 |1 CC||t...@compton.nu Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED --- Comment #5 from Tom Hughes --- Reopening bug wrongly closed by KDE janitor. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410102] Valgrind ir sanity check failure crash
https://bugs.kde.org/show_bug.cgi?id=410102 Tom Hughes changed: What|Removed |Added Resolution|WORKSFORME |--- CC||t...@compton.nu Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #5 from Tom Hughes --- Reopening bug wrongly closed by KDE janitor. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 133766] Would like more flexible suppression format
https://bugs.kde.org/show_bug.cgi?id=133766 Tom Hughes changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 CC||t...@compton.nu Resolution|WORKSFORME |--- --- Comment #5 from Tom Hughes --- Reopening bug wrongly closed by KDE janitor. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 463082] (vpsrld) vex x86->IR: unhandled instruction bytes: 0x62 0xD1 0x6D 0x8 0x72 0x10 0x18 0x62 0xD1 0x7D
https://bugs.kde.org/show_bug.cgi?id=463082 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 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||kobalicek.p...@gmail.com --- Comment #83 from Tom Hughes --- *** Bug 463082 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 462135] vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 0xFD 0x28 0x7C 0xE9 0xB1 0x2 0x62 0xF2
https://bugs.kde.org/show_bug.cgi?id=462135 --- Comment #3 from Tom Hughes --- Sure, but something has chosen to output the instruction with an EVEX prefix, which was added as part of AVX512 so you'll need the AVX512 support to have any chance of decoding it. It may well be possible to encode the instruction in other ways, but that specific example has been encoded with an EVEX prefix as you can tell from the 0x62 at the start. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 462135] vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 0xFD 0x28 0x7C 0xE9 0xB1 0x2 0x62 0xF2
https://bugs.kde.org/show_bug.cgi?id=462135 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #1 from Tom Hughes --- That's an AVX512 instruction, or at least is encoded with an EVEX prefix which means it needs the AVX512 support to work. *** 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||smuel...@chronox.de --- Comment #82 from Tom Hughes --- *** Bug 462135 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 462135] vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 0xFD 0x28 0x7C 0xE9 0xB1 0x2 0x62 0xF2
https://bugs.kde.org/show_bug.cgi?id=462135 Tom Hughes changed: What|Removed |Added Summary|unhandled instruction |vex amd64->IR: unhandled |bytes: 0x62 0xF2 0xFD 0x28 |instruction bytes: 0x62 |0x7C 0xE9 0xB1 0x2 0x62 |0xF2 0xFD 0x28 0x7C 0xE9 |0xF2|0xB1 0x2 0x62 0xF2 CC||t...@compton.nu -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 461922] Installation Failure
https://bugs.kde.org/show_bug.cgi?id=461922 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED CC||t...@compton.nu Resolution|--- |NOT A BUG --- Comment #1 from Tom Hughes --- That's not an installation failure, that's an error message telling you that it is unable to run on your system as currently configured and offering some advice on how to fix things. -- 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 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 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 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 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 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 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 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 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] 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] 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 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 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 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||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 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 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 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 342988] INT 80 not recognised on amd64
https://bugs.kde.org/show_bug.cgi?id=342988 Tom Hughes changed: What|Removed |Added CC||alfred.pola...@broadcom.com --- Comment #2 from Tom Hughes --- *** Bug 454482 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454482] vex amd64->IR: unhandled instruction bytes: 0xCD 0x80 0x89 0x45 0xFC 0x8B 0x45 0xFC 0x89 0x45
https://bugs.kde.org/show_bug.cgi?id=454482 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Tom Hughes --- We have in fact had one other report, seven years ago... *** This bug has been marked as a duplicate of bug 342988 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454482] vex amd64->IR: unhandled instruction bytes: 0xCD 0x80 0x89 0x45 0xFC 0x8B 0x45 0xFC 0x89 0x45
https://bugs.kde.org/show_bug.cgi?id=454482 --- Comment #4 from Tom Hughes --- The point really is that I don't think we've ever bothered to implement in 0x80 on x86_64 because nothing uses it. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454482] vex amd64->IR: unhandled instruction bytes: 0xCD 0x80 0x89 0x45 0xFC 0x8B 0x45 0xFC 0x89 0x45
https://bugs.kde.org/show_bug.cgi?id=454482 --- Comment #2 from Tom Hughes --- Why are you using int 0x80 to make a system call on x86_64 though? Even newer x86_32 systems have better ways to make system calls and x86_64 has never really used that for them other that in artificial hand rolled code like yours. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454482] vex amd64->IR: unhandled instruction bytes: 0xCD 0x80 0x89 0x45 0xFC 0x8B 0x45 0xFC 0x89 0x45
https://bugs.kde.org/show_bug.cgi?id=454482 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Summary|valgrind: Unrecognised |vex amd64->IR: unhandled |instruction at address |instruction bytes: 0xCD |0x40054a. (assembly code|0x80 0x89 0x45 0xFC 0x8B |for __NR_getuid32) |0x45 0xFC 0x89 0x45 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- Well which function did the compiler actually use for that? It doesn't really matter what you wrote in the source - if the compiler has decided that it's safe to replace it with memcpy (because it knows the memcpy implementation is overlap safe) then it might do that but valgrind has no way to know that so will warn about it. I'd try and reproduce it to see for myself but it's likely to be very environment sensitive and you haven't even said what version of Fedora you're using. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 --- Comment #5 from Tom Hughes --- Sorry I meant I reproduced in Fedora 35 and without having to figure out docker which is a totally unnecessary distraction. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 --- Comment #4 from Tom Hughes --- I've managed to reproduce it on Fedora 34 and it does seem to be linked to use __memmove_chk and __memmove_chk and __memcpy_chkdo seem to be different symbols in glibc (sometimes the two are the same if memcpy is known to be overlap safe) so it does seem a bit odd. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453084] Misleading error with memmove: Source and destination overlap in memcpy_chk
https://bugs.kde.org/show_bug.cgi?id=453084 --- Comment #6 from Tom Hughes --- I think this (from --trace-redir=yes) explains is: --3163534-- REDIR: 0x4a5f6c0 (libc.so.6:__memmove_chk) redirected to 0x48391ea (_vgnU_ifunc_wrapper) --3163534-- Adding redirect for indirect function 0x4a5f6c0 from 0x493ff50 -> 0x484eba0 --3163534-- REDIR: 0x493ff50 (libc.so.6:__memcpy_chk_sse2_unaligned) redirected to 0x484f220 (__memcpy_chk) So __memmove_chk is actually an IFUNC that, on first call, resolves to the optimal implementation for the current preprocessor. In this case it chose __memcpy_chk_sse2_unaligned presumably because it knows that is in fact overlap safe, so as far as valgrind is concerned the call did in fact wind up going to memcpy and hence got checked. I'm not sure there's a huge amount we can do to avoid this sadly. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 453065] memcheck warnings when using C++
https://bugs.kde.org/show_bug.cgi?id=453065 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED CC||t...@compton.nu Resolution|--- |NOT A BUG --- Comment #1 from Tom Hughes --- Notice that the size of the struct is 0 in the C version and 1 in the C++ version because C++ has added a single padding byte to the structure. That padding byte is not initialised, but you are trying to print it, hence the warning. -- 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 --- Comment #6 from Tom Hughes --- That looks the same to me if you ignore the extra bytes. The valgrind decoder doesn't know how long the instruction is (because it doesn't understand it) so it just dumps enough bytes to guarantee getting the whole thing. -- 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 --- Comment #4 from Tom Hughes --- I meant "without valgrind" there of course... -- 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 CC||t...@compton.nu --- Comment #3 from Tom Hughes --- Well it will run fine with valgrind (assuming the CPU supports the AVX512 extensions) but when running under valgrind you are running on valgrind's emulated CPU instead of the real one and that doesn't support he AVX512 extensions yet. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 164298] finitel() returns false normally but true under valgrind
https://bugs.kde.org/show_bug.cgi?id=164298 Tom Hughes changed: What|Removed |Added Resolution|--- |INTENTIONAL CC||t...@compton.nu Status|REOPENED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450458] unhandled instruction bytes: 0x37 0x48 0x83 0xF8 0x2E 0xF 0x84
https://bugs.kde.org/show_bug.cgi?id=450458 --- Comment #8 from Tom Hughes --- Well in principle we should probably treat them as non-file backed but it's going to be tricky to identify them. This is what a mapping from such a file looks like in valgrind's address map: --3993090:1: aspacem 10: file 0004033000-0004033fff4096 rwx-- d=0x001 i=445531 o=0 (8,345) So the device is 00:01 which is same as any other shared memory backed file, including files on tmpfs filesystems. I guess we could look at the filename but we'd probably want to do that when updating the map and store a flag because the point where actually want to check whether something is file backed is a hot path that needs to avoid unnecessary slowdowns. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450458] unhandled instruction bytes: 0x37 0x48 0x83 0xF8 0x2E 0xF 0x84
https://bugs.kde.org/show_bug.cgi?id=450458 --- Comment #6 from Tom Hughes --- Specifically https://github.com/zherczeg/sljit/blob/8d0f668fad91ca1d6c8afb3b72b34db41bee/sljit_src/sljitProtExecAllocator.c#L116 in sljit. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450458] unhandled instruction bytes: 0x37 0x48 0x83 0xF8 0x2E 0xF 0x84
https://bugs.kde.org/show_bug.cgi?id=450458 --- Comment #5 from Tom Hughes --- Ah the /memfd:sljit path is probably a big clue - it's using an anonymous file created with memfd_create so it is file backed but not with a real file. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450458] unhandled instruction bytes: 0x37 0x48 0x83 0xF8 0x2E 0xF 0x84
https://bugs.kde.org/show_bug.cgi?id=450458 --- Comment #4 from Tom Hughes --- Well that's quite interesting - the default is --smc-check=all-non-file which means we check for self modifying code on heap, stack and in anonymous mappings but not in file backed mappings. So it sounds like it is modifying code in a file backed mapping which is quite an odd thing to do! Either that or there is some sort of bug in our detection of whether a mapping is file backed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450458] unhandled instruction bytes: 0x37 0x48 0x83 0xF8 0x2E 0xF 0x84
https://bugs.kde.org/show_bug.cgi?id=450458 --- Comment #2 from Tom Hughes --- Checked the December 2021 edition of the manual now and nothing seems to have changed so that is not a valid instruction. Either this is self modifying code that hasn't been detected (does --smc-check=all help?) or the program has taken a bogus branch somewhere - are there any warnings before that about bad memory accesses? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450458] unhandled instruction bytes: 0x37 0x48 0x83 0xF8 0x2E 0xF 0x84
https://bugs.kde.org/show_bug.cgi?id=450458 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Well 0x37 is the AAA (ASCII Adjust After Addition) instruction which seems pretty unlikely, not least because it's not valid in 64 bit mode. I'm using a 2019 edition of the Intel manual so maybe it has been reused in 64 bit mode now - are you using a very recent processor and did you compile with -march=native or similar? -- 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 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 446754] Improve error codes from alloc functions under memcheck
https://bugs.kde.org/show_bug.cgi?id=446754 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- I think that's only true for memalign (which the manual page says is obsolete) and aligned_alloc (which appears to be an alias for memalign even the manual page says it has an extra restriction) though, and posix_memalign does enforce power of two and a multiple of sizeof(void *) as the manual page says: https://elixir.bootlin.com/glibc/latest/source/malloc/malloc.c#L5553 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] AMD64 xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 Tom Hughes changed: What|Removed |Added CC||k...@tastytea.de --- Comment #27 from Tom Hughes --- *** Bug 446669 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 446669] vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0xF8 0x10 0xED 0x7 0x20 0x0 0x0 0x48
https://bugs.kde.org/show_bug.cgi?id=446669 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 339596 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 446429] vex x86->IR: unhandled instruction bytes: 0xFB 0xFF 0xFF 0x8B
https://bugs.kde.org/show_bug.cgi?id=446429 --- Comment #4 from Tom Hughes --- Well you've got an invalid write reported there so the first thing you should do is fix that - once an invalid write has happened the state of your program is undefined because something somewhere was been overwritten with something unintended. There's also an indication of something odd happening to your stack pointer - are you using some sort of user space threading to context switch? or creating very large arrays on the stack? Does adding the switch it suggested help? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 446429] vex x86->IR: unhandled instruction bytes: 0xFB 0xFF 0xFF 0x8B
https://bugs.kde.org/show_bug.cgi?id=446429 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Well 0xFB is STI which sets the interrupt flag to enable interrupts which is presumably a privileged instruction that a user mode program shouldn't be trying to use. It seems more likely that you've somehow jumped to a bogus address and are trying to execute something that isn't a valid instruction stream, or you have self modifying code that valgrind hasn't detected. Does --smc-check=all help at all? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 446410] illegal instruction: _mm256_loadu_si256
https://bugs.kde.org/show_bug.cgi?id=446410 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- That's not an instruction, it's the name of an intrinsic function. If you're reporting an instruction decode failure in valgrind please instead the error message that valgrind reported as it will include all the details we need to identify the problem instruction. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 446236] Issues with Valgrind 3.8.1 version, after compiler upgrade
https://bugs.kde.org/show_bug.cgi?id=446236 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- We don't support or not support particular toolchains. Of course a new compiler might generate new instructions that an old one didn't and that might include an instruction that a given version of valgrind doesn't know how to emulate but if that happens if will give full details of the problem when it exits. If you want help you're going to need to provide the output from valgrind when it crashes so that we can diagnose the problem. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445627] Query on Leak summary
https://bugs.kde.org/show_bug.cgi?id=445627 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG CC||t...@compton.nu --- Comment #1 from Tom Hughes --- This is a bug tracker - enquiries about how to use valgrind are better directed to the users mailing list. If the leak summary is printed immediately then the program you are running is exiting immediately and you're not actually running your program under valgrind. Most likely you have run valgrind on a shell script or other launcher that then launches the real program and you're not using --trace-children=yes so valgrind exits when that initial launcher does and tells you about leaks in the launcher. If you are using --trace-children=yes then valgrind will still be tracing the launched program and will issue an additional report when that exits. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445011] SIGCHLD is sent when valgrind is used and getservbyname() function is invoked on Fedora 35
https://bugs.kde.org/show_bug.cgi?id=445011 --- Comment #7 from Tom Hughes --- I did some looking at this and I think probably m_signals.c needs to provide a way to register pids which should be ignored and not passed on to the client when SIGCHLD arrives. Then either VG_(fork) or readelf.c could register the pids - currently the only direct user of VG_(fork) is readelf.c for starting the debuginfo fetcher. The only other use of VG_(fork) is to implement VG_(spawn) on non-solaris systems and in turn that is only used by VG_(system) which does make some attempt to deal with SIGCHLD though I'm not sure it's correct - aside from anything else it changes the CHLD handler after the fork has already been done so there would appear to be a race condition. Users of VG_(system) are the PDB and MACHO debug readers which use it to run external tools and the gdb server, so it's possible those can also trigger false SIGCHLD reports to the client. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445011] SIGCHLD is sent when valgrind is used and getservbyname() function is invoked on Fedora 35
https://bugs.kde.org/show_bug.cgi?id=445011 --- Comment #2 from Tom Hughes --- Ah it's the children that are created to run /usr/bin/debuginfod-find and fetch debug information. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445011] SIGCHLD is sent when valgrind is used and getservbyname() function is invoked on Fedora 35
https://bugs.kde.org/show_bug.cgi?id=445011 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Well there must be a child that has exited - valgrind isn't going to suddenly create new processes unless the client program requests it and it's not going to just invent signals. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444431] Incorrectly assumes static text is uninitialized
https://bugs.kde.org/show_bug.cgi?id=31 --- Comment #2 from Tom Hughes --- Also, what version of valgrind are you using? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444431] Incorrectly assumes static text is uninitialized
https://bugs.kde.org/show_bug.cgi?id=31 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Really, nothing would work properly if that was actually the case. Whatever is really going on I'm sure it's more complicated than that but we're going to need to see some example code that demonstrates the problem. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444264] Valgrind is not able to detect sample array bound read and write.
https://bugs.kde.org/show_bug.cgi?id=444264 Tom Hughes changed: What|Removed |Added Resolution|--- |NOT A BUG CC||t...@compton.nu Status|REPORTED|RESOLVED --- Comment #1 from Tom Hughes --- Place see https://valgrind.org/docs/manual/faq.html#faq.overruns for the explanation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443833] unhandled amd64-linux syscall: 326
https://bugs.kde.org/show_bug.cgi?id=443833 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE CC||t...@compton.nu --- Comment #1 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 407218 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 407218] Add support for the copy_file_range syscall
https://bugs.kde.org/show_bug.cgi?id=407218 Tom Hughes changed: What|Removed |Added CC||skrr...@yandex.ru --- Comment #8 from Tom Hughes --- *** Bug 443833 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 419562] PR_SET_PTRACER error with Ubuntu on WSL
https://bugs.kde.org/show_bug.cgi?id=419562 Tom Hughes changed: What|Removed |Added CC||lean...@21csw.com --- Comment #4 from Tom Hughes --- *** Bug 443426 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443426] Getting valgrind: the 'impossible' happened: Unsupported arch_prctl option when running valgring
https://bugs.kde.org/show_bug.cgi?id=443426 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 419562 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 442061] Valgrind: very slow execution under Fedora 34
https://bugs.kde.org/show_bug.cgi?id=442061 Tom Hughes changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|DUPLICATE |--- --- Comment #3 from Tom Hughes --- I'm going to remove that duplicate flag because I think this is related but not the same. The issue here is that because debuginfod is enabled in F34 we now fetch the debug information for glibc and hence have to parse it which wouldn't have happened before unless you had installed the debuginfo manually. That interacts with a separate issue where we do more work parsing the debug information than is really needed and I thought there was a bug for that but I can't find it right now. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 442061] Valgrind: very slow execution under Fedora 34
https://bugs.kde.org/show_bug.cgi?id=442061 Tom Hughes changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE CC||t...@compton.nu --- Comment #2 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 435908 *** -- You are receiving this mail because: You are watching all bug changes.
