|
From: Greg H.
|
This question doesn't seem to be addressed in the FAQ, and the list
archive appears to be broken right now ("Either your mailing list name
was misspelled or your mailing list has not been archived yet"), so I
will ask it here.
My question: how can I determine which bytes are uninitialized when I
see a "System call param writev(vector[...]) contains uninitialized or
unaddressable bytes(s)" message? If I can't determine that after the
fact, is there any way I can generate errors on uninitialized memory
copies and sort through those? Tweaking the valgrind source code is a
workable option for me, since I'm not using a prebuilt binary or
anything.
The background: I've been trying to run evolution 1.4 (compiled from
source with gcc 3.2.2 on a Red Hat 9 system) under valgrind 20030725,
to help diagnose some sporadic crashes which appear to result from
memory corruption. But I've run into an intermediate problem; right
when GConf2 starts up and tries to ping the existing gconfd using
ORBit2, I see:
==6351== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s)
If I attach to the process with gdb, I find that the iovecs parameter
contains two iovecs, one with 12 bytes and one with 84 bytes. Looking
at the code, the 96 bytes of data in the iovecs are assembled from a
wide variety of sources, all of which appear to be kosher, but it's
hard to be sure. If I continue past this point, the evolution
behavior under valgrind quickly departs from the normal observed
behavior--the gconf_engine_connect() db variable receives an
uninitialized value and I get a crash, where normally that variable
receives a valid value and evolution starts up fine. My guess is that
the uninitialized data in the iovecs (assuming there is any) is
receiving different values under valgrind, causing different behavior.
Thanks for all the good work.
|