https://bugs.kde.org/show_bug.cgi?id=487862
--- Comment #8 from John Reiser <jrei...@bitwagon.com> ---
(In reply to Mark Wielaard from comment #6)
> BTW it seems this whole discussion is duplicated in the comments of
> memcheck/mc_main.c mc_post_clo_init ()
> // - The current inaccuracy has caused maybe one complaint in seven
> years(?)
> // - Relying on the zeroed-ness of whole brk'd pages is pretty grotty... I
> // doubt most programmers know the above information.
> // So I'm not terribly unhappy with marking it as undefined. --njn.
>
> Which was written in 2009. So maybe times have changed since then. But I
> don't really remember any false positive report about this.
What has changed is very large apps such as qemu-user-* which depend on
dozens of "random" libraries, and the system
builders/maintainers/administrators
who tired of their own version of "dll hell" due to dependency tracking,
and the users (including "systematic" users with scripts) who got tired of
multi-second initialization of all those shared libraries; all gained new
appreciation
for -static builds of ET_EXEC (no shared libraries at all!) which initialize
in a flash
and have robust configuration (none!) for end users. Disk space is cheap for
many
such users; time is not. qemu-user has grown into a predictable evolution which
avoids nearly all "security" incidents which otherwise might argue for using
shared libraries.
But then "corner case" users of qemu-user-* (etc), the users who just might
find a bug or two,
discover that memcheck is much less useful. Gdb and debuginfo have no trouble
identifying malloc/free/sbrk+sys_brk etc., but memcheck does not recognize
them.
Re-building the app from source (and avoiding -static+ET_EXEC) takes hours of
time
and almost 10 GB of disk space, uses 4 different build systems (make, cmake,
meson, ninja)
and two runtime support systems (Go-lang and C-lang).
Being highly motivated for the particular case of qemu-mips*-static, I have
developed
binary patches that zero the new region of {_dl_early_allocate, malloc} +
{expanding sbrk/sys_brk}.
This is not as good as proper memcheck accounting, but it suits my purpose
of finding uninit local variables in what would otherwise be a blizzard of
Uninit complaints
caused by memcheck not recognizing when to mark bytes from sys_brk as Defined.
Without the patches, memcheck finds
==375110== ERROR SUMMARY: 9646 errors from 125 contexts (suppressed: 0 from
0)
before the process aborts with
==375110== Warning: ignored attempt to set SIGRT32 handler in sigaction();
==375110== the SIGRT32 signal is used internally by Valgrind
fatal error: sigaction failed [from Go-lang]
Memcheck should find some way to avoid relying on SIGRT32, perhaps using
pipefs.
The histogram of memcheck Uninit complaints (before patching) begins:
108 ==375110== at 0x64E006: _dl_early_allocate (in
/usr/bin/qemu-mipsel-static)
16 ==375110== at 0x63B5AB: brk (in /usr/bin/qemu-mipsel-static)
15 ==375110== at 0x5FDC36: __pthread_enable_asynccancel (in
/usr/bin/qemu-mipsel-static)
15 ==375110== at 0x5FDC2B: __pthread_enable_asynccancel (in
/usr/bin/qemu-mipsel-static)
14 ==375110== at 0x5FDCB9: __pthread_disable_asynccancel (in
/usr/bin/qemu-mipsel-static)
14 ==375110== at 0x5FDCB1: __pthread_disable_asynccancel (in
/usr/bin/qemu-mipsel-static)
14 ==375110== at 0x5FDC87: __pthread_disable_asynccancel (in
/usr/bin/qemu-mipsel-static)
10 ==375110== at 0x61BA21: __strcmp_avx2 (in
/usr/bin/qemu-mipsel-static)
5 ==375110== at 0x4E6CE6: mmap_unlock (mmap.c:39)
5 ==375110== at 0x4E6A7F: mmap_lock (mmap.c:32)
3 ==375110== at 0x606D85: _int_free (in /usr/bin/qemu-mipsel-static)
So far there is one uninit local:
==375110== Uninitialised value was created by a stack allocation
==375110== at 0x4808D0: process_string_cmd.constprop.0 (gdbstub.c:1368)
--
You are receiving this mail because:
You are watching all bug changes.
