|
From: Shachar S. <sh...@sh...> - 2014-05-03 15:36:00
|
Hi all, I'm running Valgrind on fakeroot-ng (which used to be not possible, so kudus!) and getting the following error: ==23945== Thread 3: ==23945== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==23945== at 0x6368EFB: send (send.c:31) ==23945== by 0x43FC20: SyscallHandlerTask::proxy_call(std::function<void ()> const&) (parent.cpp:211) ==23945== by 0x43DD9B: pid_state::end_handling() (parent.cpp:708) ==23945== by 0x44649B: sys_getuid(int, int, pid_state*) (credentials.cpp:32) ==23945== by 0x4404D3: SyscallHandlerTask::process_syscall() (parent.cpp:310) ==23945== by 0x43FB7D: SyscallHandlerTask::run() (parent.cpp:202) ==23945== by 0x4332A9: worker_queue::worker() (worker_queue.cpp:97) ==23945== by 0x437808: void std::_Mem_fn<void (worker_queue::*)()>::operator()<, void>(worker_queue*) const (in /home/sun/sources/myfoss/fakeroot-ng/git/build_dbg/fakeroot-ng) ==23945== by 0x437758: void std::_Bind_simple<std::_Mem_fn<void (worker_queue::*)()> (worker_queue*)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (functional:1732) ==23945== by 0x437660: std::_Bind_simple<std::_Mem_fn<void (worker_queue::*)()> (worker_queue*)>::operator()() (functional:1720) ==23945== by 0x4375F9: std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (worker_queue::*)()> (worker_queue*)> >::_M_run() (thread:115) ==23945== by 0x5BEC9BF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20) ==23945== Address 0x8980ad4 is on thread 3's stack This is generated by the following code: http://sourceforge.net/p/fakerootng/source/ci/754928033faa0f235df244744d12e5d2da2fb55b/tree/parent.cpp#l211 thread_request is defined like so: struct thread_request { enum request_type { THREADREQ_PTRACE, THREADREQ_PROXYCALL, } request; union { struct { __ptrace_request request; pid_t pid; void *addr; void *data; } ptrace; struct { const std::function< void() > *worker; } proxy; } u; }; The source of the error seems to be padding and data variables not used in my particular scenario. While it's true they are passed, uninitialized, to "sendto", the other end will parse them according to the same criteria, and will also ignore them. Since the other end of this socket is a process also managed by the same valgrind instance, it is theoretically possible for valgrind to postpone the error report until actual use after the read. I'm not sure that is a useful application of the developer's time, however. I just wanted to make sure that: 1. This is, indeed, a false positive (i.e. - that I'm not missing something important). and 2. That there is nothing to do about it. Thanks, Shachar |