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
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
