https://bugs.kde.org/show_bug.cgi?id=456171
--- Comment #8 from Paul Floyd <pjfl...@wanadoo.fr> --- (In reply to obi...@gmail.com from comment #7) > I'm not entirely sure why Valgrind doesn't track this memory, but in any > case there should be a guarantee that it's okay to access this memory, which > is why I attempted to do what I attempted to do with this patch - ignore > accesses to that memory. How can memcheck know? It's intercepting all of the 'malloc' and 'new' family functions so it knows about them. It also created the client stack so it knows the base and also via the stack pointer in VEX the bottom of the stack. Here's one error ==5238== Invalid read of size 8 ==5238== at 0x490B56E: ??? (in /lib/libc.so.7) ==5238== by 0x490B778: setproctitle (in /lib/libc.so.7) ==5238== by 0x2018C3: main (setproctitle.c:6) ==5238== Address 0x7fffffffefe0 is not stack'd, malloc'd or (recently) free'd This is the top of the address space --5238:1: aspacem 50: RSVN 0800000000-7fffdfffefff 131039g ----- SmFixed --5238:1: aspacem 51: ANON 7fffdffff000-7ffffffdefff 511m ----- --5238:1: aspacem 52: ANON 7ffffffdf000-7fffffffefff 131072 rw--- --5238:1: aspacem 53: ANON 7ffffffff000-7fffffffffff 4096 r-x-- --5238:1: aspacem 54: RSVN 800000000000-ffffffffffffffff 16383e ----- SmFixed 0x7fffffffefe0 is on the Valgrind host's stack. That's what I would expect. FreeBSD doesn't know about Valgrind's phoney auxv for its guest, so the sysctl interacts with the host auxv. Valgrind doesn't track its own memory. The expectation is that host and guest memory are separate and that the guest doesn't access host memory. > Again though, there may be (and actually probably is) a much more elegant > solution to this which I'm not seeing right now! The alternative that I see is to add special handling for kern.ps_strings similar to what is being done for kern.userstack -- You are receiving this mail because: You are watching all bug changes.
