[valgrind] [Bug 371471] Valgrind complains about non legit memory leaks on placement new (C++)
https://bugs.kde.org/show_bug.cgi?id=371471 Tom Hughes changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tom Hughes --- So this is the leak it is reporting: ==24123== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1 ==24123==at 0x62228BAD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==24123==by 0x624C0A5F: ??? (in /usr/lib64/libstdc++.so.6.0.22) ==24123==by 0x6160CD89: call_init.part.0 (in /usr/lib64/ld-2.23.so) ==24123==by 0x6160CE9A: _dl_init (in /usr/lib64/ld-2.23.so) ==24123==by 0x615FDCB9: ??? (in /usr/lib64/ld-2.23.so) So it's nothing to do with the placement new but rather is some initialisation inside the standard library. It's also still reachable when the program terminates, so not really a leak at all, which is why the details aren't shown by default. In the newly released 3.12.0 it goes away anyway because we now call the libstdc++ cleanup routine at exit by default. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371471] Valgrind complains about non legit memory leaks on placement new (C++)
https://bugs.kde.org/show_bug.cgi?id=371471 --- Comment #4 from Tom Hughes --- I'm pretty sure it's not the same anyway as the other bug is about static objects, and there are none here. This is almost certainly something different - the fact that it is reporting two allocations suggests that it is trapping the placement new and treating it as a real allocation that is then never freed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371471] Valgrind complains about non legit memory leaks on placement new (C++)
https://bugs.kde.org/show_bug.cgi?id=371471 --- Comment #3 from Tom Hughes --- Also that code doesn't even compile: bericote [/tmp] % g++ -std=c++14 -o x x.cpp x.cpp: In function ‘int main()’: x.cpp:12:17: error: no matching function for call to ‘operator new(sizetype, A*&)’ new (obj) A(20); ^ : note: candidate: void* operator new(long unsigned int) : note: candidate expects 1 argument, 2 provided -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371471] Valgrind complains about non legit memory leaks on placement new (C++)
https://bugs.kde.org/show_bug.cgi?id=371471 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- Well it might be the same as that or it might not - it's hard to tell because the leak details have been suppressed from the log. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368873] Please add FreeBSD to the supported OS list
https://bugs.kde.org/show_bug.cgi?id=368873 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- This isn't something we can just do - somebody will need to volunteer to bring the port to us and work with us to integrate it. Supporting a new platform in valgrind is a significant amount of work and even though there is an existing port I'm sure it would need a fair amount of effort to bring it up to date and to respond to the inevitable review comments and requests for changes needed to merge it. We would really also want to have one or more people prepared to maintain it on an ongoing basis as none of the current developers will have any experience of FreeBSD or will be running any FreeBSD systems. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368791] unhandled syscall: 167
https://bugs.kde.org/show_bug.cgi?id=368791 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- What platform (OS/architecture) is this? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes
https://bugs.kde.org/show_bug.cgi?id=368507 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Yes there is a compiled in memory limit imposed by the addressing scheme valgrind uses for it's shadow memory. See https://stackoverflow.com/questions/8644234/why-is-valgrind-limited-to-32-gb-on-64-bit-architectures for more information and how to patch valgrind to allow larger address spaces. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 365258] Reading syms from /valgrind/lib/valgrind/memcheck-arm-linux bject doesn't have a dynamic symbol table
https://bugs.kde.org/show_bug.cgi?id=365258 Tom Hughes changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Tom Hughes --- That's not an error, it's just an informational message. There is no way to dynamically link that file. When valgrind says the redirection is mandatory it does so for a very good reason, and you can't just comment out the line to stop it complaining! You need to install debug symbols for glibc, or stop it being stripped, or something. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 365258] Reading syms from /valgrind/lib/valgrind/memcheck-arm-linux bject doesn't have a dynamic symbol table
https://bugs.kde.org/show_bug.cgi?id=365258 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Well it's statically linked so of course it doesn't have a dynamic symbol table. I don't understand what that has to do with the illegal instruction though? or why you decided to comment out that line? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359950] Wrong result comparing doubles on x87
https://bugs.kde.org/show_bug.cgi?id=359950 --- Comment #6 from Tom Hughes --- Note that I didn't mean spills/reloads that valgrind's internal implementation does, but rather any spills/reloads that the original compiler generated. My understanding was that those would use the normal memory location for the variable, which as a double would only be 64 bits and hence would lose precision. Are you saying that gcc instead allocates an 80 bit temporary location for the spill to avoid losing precision? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 355803] Add Lustre's IOC_MDC_GETFILESTRIPE ioctl
https://bugs.kde.org/show_bug.cgi?id=355803 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #3 from Tom Hughes --- Is this something that is in the upstream kernel.org kernels? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 355803] Add Lustre's IOC_MDC_GETFILESTRIPE ioctl
https://bugs.kde.org/show_bug.cgi?id=355803 --- Comment #4 from Tom Hughes --- Note that in general patches will be reviewed when we have a release upcoming, so don't worry if it sits around for a while. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362276] Valgrind got SIGSEGV while doing synchronization of multi-threaded tree and copy audio buffers
https://bugs.kde.org/show_bug.cgi?id=362276 Tom Hughes changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362276] Valgrind got SIGSEGV while doing synchronization of multi-threaded tree and copy audio buffers
https://bugs.kde.org/show_bug.cgi?id=362276 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #4 from Tom Hughes --- Were there any warnings from memcheck before valgrind crashed? Although that crash appears as a valgrind internal error really it is most likely just a result of your malloc heap being corrupt given that it occurs in valgrind's malloc implementation. So the first thing to do is to make sure that any issues valgrind has already reported before that are fixed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] valgrind: m_commandline.c:79 (read_dot_valgrindrc): Assertion 'n >= 0 && n <= stat_buf.size+1' failed.
https://bugs.kde.org/show_bug.cgi?id=362223 --- Comment #10 from Tom Hughes --- Please use the mailing lists for general questions - it's not really appropriate for the bug tracker. See http://valgrind.org/support/mailing_lists.html for more information. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] valgrind: m_commandline.c:79 (read_dot_valgrindrc): Assertion 'n >= 0 && n <= stat_buf.size+1' failed.
https://bugs.kde.org/show_bug.cgi?id=362223 --- Comment #8 from Tom Hughes --- Well it's a bug that valgrind crashes when .valgrindrc is a folder, but the easy workaround is for you to remove that folder (it serves no purpose - firstly because .valgrindrc is optional and secondly because it should be a file). If you can't delete it then it suggests you have filesystem corruption and you should probably fsck your filesystem. The .valgrindrc is nothing to do with valgrind itself, so removing valgrind was neither necessary not appropriate really. The .valgrindrc file is just somewhere where you can put configuration options to be applied by default whenever you run valgrind. It's not owned by your system's valgrind package (or at least it shouldn't be...) but rather is something you would normally create yourself. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] valgrind: m_commandline.c:79 (read_dot_valgrindrc): Assertion 'n >= 0 && n <= stat_buf.size+1' failed.
https://bugs.kde.org/show_bug.cgi?id=362223 --- Comment #6 from Tom Hughes --- Well 4K seems extremely large, but it seems the real problem is that your .valgrindrc is a directory: read(3, 0x802001230, 4096) = -1 EISDIR (Is a directory) It is supposed to be a file... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] valgrind: m_commandline.c:79 (read_dot_valgrindrc): Assertion 'n >= 0 && n <= stat_buf.size+1' failed.
https://bugs.kde.org/show_bug.cgi?id=362223 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- This doesn't really make any sense - it appears that read() has returned more bytes than stat() says exist in the file! How big is your .valgrindrc file? Can you strace valgrind and attach the trace? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361810] valgrind duplicate stdin after fork
https://bugs.kde.org/show_bug.cgi?id=361810 --- Comment #13 from Tom Hughes --- I'm pretty sure that it's a bug in glibc that should be fixed anyway - you're only supposed to call __libc_freeres when the process is exiting and in that case there shouldn't be any need to rewind any descriptor if you discard the buffer. Of course there's an interesting issue here in that I suspect forking and calling setvbuf() on a channel in the fork will have much the same effect on the parent that you are sharing the descriptor with... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361810] valgrind duplicate stdin after fork
https://bugs.kde.org/show_bug.cgi?id=361810 --- Comment #11 from Tom Hughes --- See http://valgrind.org/docs/manual/faq.html#faq.exit_errors for more information. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361810] valgrind duplicate stdin after fork
https://bugs.kde.org/show_bug.cgi?id=361810 --- Comment #10 from Tom Hughes --- The call to __libc_freeres is not normally made at all - it is forced by valgrind (unless you use that switch) so that people won't moan about "still reachable" blocks of memory in the leak report due to glibc still having stuff allocated. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361810] valgrind duplicate stdin after fork
https://bugs.kde.org/show_bug.cgi?id=361810 --- Comment #6 from Tom Hughes --- It's something in glibc doing it when __libc_freeres is run as the child exits. If you add run-libc-freeres=no to the valgrind options then it doesn't happen. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361810] valgrind duplicate stdin after fork
https://bugs.kde.org/show_bug.cgi?id=361810 --- Comment #8 from Tom Hughes --- Of course the buffer isn't really shared (this is fork, not threads...) but the file position is. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361810] valgrind duplicate stdin after fork
https://bugs.kde.org/show_bug.cgi?id=361810 --- Comment #7 from Tom Hughes --- I think the problem is that __libc_freeres calls (among many other things) the _IO_unbuffer_write to free the buffers for stdio streams. That "unbuffers" each file by calling _IO_SETBUF (fp, NULL, 0) to drop the buffer, but that (which is just the internal implementation of setbuf/setvbuf) rewinds the stream over any data which has been read into the buffer but not yet consumed. Of course when the buffer is shared between multiple processes the question of what has been consumed is something of an open one... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361810] valgrind duplicate stdin after fork
https://bugs.kde.org/show_bug.cgi?id=361810 --- Comment #5 from Tom Hughes --- Ah, if you add the childs you will see each one do: 3992 lseek(0, -8, SEEK_CUR)= 4 for some reason... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361810] valgrind duplicate stdin after fork
https://bugs.kde.org/show_bug.cgi?id=361810
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #4 from Tom Hughes ---
Frankly it makes no sense at all. Here's an strace of that valgrind, from the
first read on fd 0 to the second:
read(0, "abc\ndef\nghi\n", 4096)= 12
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 3114
read(1028, "J", 1) = 1
pipe2([4, 5], O_CLOEXEC)= 0
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x60262190) = 3115
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 3114
gettid()= 3114
write(1029, "K", 1) = 1
sched_yield() = 0
gettid()= 3114
read(1028, "K", 1) = 1
close(5)= 0
gettid()= 3114
write(1029, "L", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
read(4, "\2\0\0\0", 4) = 4
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 3114
read(1028, "L", 1) = 1
close(4)= 0
gettid()= 3114
write(1029, "M", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
wait4(3115, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3115
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3115, si_uid=2067,
si_status=0, si_utime=1, si_stime=0} ---
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 3114
read(1028, "M", 1) = 1
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(0x60224000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x60224000
gettid()= 3114
write(1029, "N", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
write(1, "mask 2 buf abc\n", 15)= 15
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 3114
read(1028, "N", 1) = 1
pipe2([4, 5], O_CLOEXEC)= 0
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x60262190) = 3116
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 3114
gettid()= 3114
write(1029, "O", 1) = 1
sched_yield() = 0
gettid()= 3114
read(1028, "O", 1) = 1
close(5)= 0
gettid()= 3114
write(1029, "P", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
read(4, "\2\0\0\0", 4) = 4
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 3114
read(1028, "P", 1) = 1
close(4)= 0
gettid()= 3114
write(1029, "Q", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
wait4(3116, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3116
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3116, si_uid=2067,
si_status=0, si_utime=1, si_stime=0} ---
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 3114
read(1028, "Q", 1) = 1
gettid()= 3114
write(1029, "R", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
write(1, "mask 2 buf def\n", 15)= 15
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 3114
read(1028, "R", 1) = 1
pipe2([4, 5], O_CLOEXEC)= 0
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x60262190) = 3117
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()
[valgrind] [Bug 360188] Valgrind does not build
https://bugs.kde.org/show_bug.cgi?id=360188 Tom Hughes changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||t...@compton.nu --- Comment #1 from Tom Hughes --- This is a bug in gcc which should be reported to them as instructed in the error message from the compiler. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359950] Wrong result comparing doubles on x87
https://bugs.kde.org/show_bug.cgi?id=359950 --- Comment #3 from Tom Hughes --- Although I'm not clear if that is what has happened here (and this should only happen when not running under valgrind) that's not actually true with x87 because if the compiler chooses to move one of the values from the FP stack to memory in the middle of the comparisons for any reason it will get converted from 80 bit to 64 bit and it's value will change... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359950] Wrong result comparing doubles on x87
https://bugs.kde.org/show_bug.cgi?id=359950 Tom Hughes changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Please read the "limitations" section of the manual at http://valgrind.org/docs/manual/manual-core.html#manual-core.limits especially the part about x86 floating point, and in particular this: "Precision: There is no support for 80 bit arithmetic. Internally, Valgrind represents all such "long double" numbers in 64 bits, and so there may be some differences in results." That is likely why your program behaves differently under valgrind. Your program is essentially not well defined anyway though, as floating point calculations are always imprecise so you should not expect to be able to compare a floating point result for equality with an integer version of the same calculation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 --- Comment #4 from Tom Hughes --- At least I thought it did, because I remember it being discussed recently, bit I can't find it right now... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 --- Comment #3 from Tom Hughes --- What you're missing is that valgrind imposes it's own limit of 8Mb on the stack, which you have clearly hit given the size it reported. Just looking at the memory map won't help you. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Hasn't it told you exactly what cause the fault? You ran out of stack space... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359503] Add missing syscalls for aarch64 (arm64)
https://bugs.kde.org/show_bug.cgi?id=359503 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #3 from Tom Hughes --- How many of these have you actually tested though? The point of leaving them commented out rather than just enabling them all is to wait until people find something that is actually using them so that we can get some sort of view of whether they work when we enable them. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 353370] RDRAND amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0 0x72 0x4 0xFF 0xC9
https://bugs.kde.org/show_bug.cgi?id=353370 Tom Hughes changed: What|Removed |Added CC||brat...@opera.com --- Comment #13 from Tom Hughes --- *** Bug 358988 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 358988] rdrand support missing: unhandled instruction bytes: 0x48 0xF 0xC7 0xF1 ...
https://bugs.kde.org/show_bug.cgi?id=358988 Tom Hughes changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||t...@compton.nu --- Comment #1 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 353370 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 212352] vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC (FCOM)
https://bugs.kde.org/show_bug.cgi?id=212352 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #2 from Tom Hughes --- Committed as VEX r3207 with tests in valgrind r15779. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 212352] vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC (FCOM)
https://bugs.kde.org/show_bug.cgi?id=212352 Tom Hughes changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253451] AMD64 VEX is missing support for various instructions
https://bugs.kde.org/show_bug.cgi?id=253451 Bug 253451 depends on bug 212352, which changed state. Bug 212352 Summary: vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC (FCOM) https://bugs.kde.org/show_bug.cgi?id=212352 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 303877] valgrind doesn't support compressed debuginfo sections.
https://bugs.kde.org/show_bug.cgi?id=303877 --- Comment #17 from Tom Hughes --- That's certainly useful to know about - it even has an "inflate only" version. It will still need some patching to stop it use memcpy/memset etc. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 303877] valgrind doesn't support compressed debuginfo sections.
https://bugs.kde.org/show_bug.cgi?id=303877 --- Comment #15 from Tom Hughes --- It's highly unlikely that there will be any quick progress, because any fix would be require valgrind to be able to decompress zlib compressed data but valgrind is not able to link to libraries so we can't just use zlib like most programs would. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 358620] ARM: unhandled syscall: 357
https://bugs.kde.org/show_bug.cgi?id=358620 Tom Hughes changed: What|Removed |Added Summary|WARNING: unhandled syscall: |ARM: unhandled syscall: 357 |357 | CC||t...@compton.nu -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 358620] ARM: unhandled syscall: 357
https://bugs.kde.org/show_bug.cgi?id=358620 --- Comment #1 from Tom Hughes --- This is epoll_create1. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357338] disInstr(arm64): unhandled instruction 0x5E140020
https://bugs.kde.org/show_bug.cgi?id=357338 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Summary|Unhandled instruction for |disInstr(arm64): unhandled |SHA instructions libcrypto |instruction 0x5E140020 |Boring SSL | -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357928] valgrind: m_mallocfree.c:303 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed
https://bugs.kde.org/show_bug.cgi?id=357928 --- Comment #3 from Tom Hughes --- So there are no other valgrind messages before that one? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357928] valgrind: m_mallocfree.c:303 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed
https://bugs.kde.org/show_bug.cgi?id=357928 Tom Hughes changed: What|Removed |Added Summary|Thread 1: status = |valgrind: |VgTs_Runnable |m_mallocfree.c:303 ||(get_bszB_as_is): Assertion ||'bszB_lo == bszB_hi' failed -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357928] Thread 1: status = VgTs_Runnable
https://bugs.kde.org/show_bug.cgi?id=357928 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Have you ruled out problems in your program as advised by the message? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357833] Valgrind is broken on recent linux kernel
https://bugs.kde.org/show_bug.cgi?id=357833 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- I presume that this code in coregrind/m_main.c is the issue (so will affect all tools, not just memcheck): //-- // Get the current process datasize rlimit, and set it to zero. // This prevents any internal uses of brk() from having any effect. // We remember the old value so we can restore it on exec, so that // child processes will have a reasonable brk value. VG_(getrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data)); zero.rlim_max = VG_(client_rlimit_data).rlim_max; VG_(setrlimit)(VKI_RLIMIT_DATA, &zero); The logic is self-explanatory, but equally it seems it is only an attempt to detect mistakes in valgrind, so that any attempt to allocate memory with brk() would fail. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357781] unhandled amd64-linux syscall: 317
https://bugs.kde.org/show_bug.cgi?id=357781 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Tom Hughes --- *** This bug has been marked as a duplicate of bug 345414 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 345414] I get the following when I ran valgrind WARNING: unhandled syscall: 317
https://bugs.kde.org/show_bug.cgi?id=345414 Tom Hughes changed: What|Removed |Added CC||jb.1234a...@gmail.com --- Comment #7 from Tom Hughes --- *** Bug 357781 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 92036] A wish for ANSI Colors in the output of valgrind
https://bugs.kde.org/show_bug.cgi?id=92036 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #3 from Tom Hughes --- How many people actually send valgrind output to a console though? I always send it to a file (which would presumably disable colouring) in order to avoid it getting mixed up with other output from the program, and then tail that file in a different window or look at it when the run has finished. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357035] Uninitialized variable of type double is reported twice in intel-compiled application.
https://bugs.kde.org/show_bug.cgi?id=357035 Tom Hughes changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Tom Hughes --- Thanks for confirming that. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357035] Uninitialized variable of type double is reported twice in intel-compiled application.
https://bugs.kde.org/show_bug.cgi?id=357035 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Unfortunately because you've blanked out the addresses it's hard to tell what's going on here... If the addresses are different then the answer would seem to be simply that the compiler is generating code that reads the variable twice. Even if they're the same then the only reasonable explanation I can see is that the compiled code is passing through that instruction twice when run. In short I suspect this is simply an artefact of the code generated by the compiler rather than any bug in valgrind. -- You are receiving this mail because: You are watching all bug changes.
