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.
|
After rooting through the valgrind source, I discovered that I am
blind, and the address info I coveted is displayed between two partial
stack traces:
==6579== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s)
==6579== at 0x40181C24: vgAllRoadsLeadToRome_writev (vg_intercept.c:108)
==6579== by 0x40181C60: __writev (vg_intercept.c:732)
==6579== by 0x407C311D: (within /usr/lib/liblinc.so.1.0.0)
==6579== by 0x407C32AB: linc_connection_writev (in /usr/lib/liblinc.so.1.0.0)
==6579== Address 0x4402E83E is 10 bytes inside a block of size 2048 alloc'd
==6579== at 0x4002942A: malloc (vg_replace_malloc.c:153)
==6579== by 0x4112F558: g_malloc (in /usr/lib/libglib-2.0.so.0.200.1)
==6579== by 0x4078531E: get_next_indirect (giop-send-buffer.c:273)
==6579== by 0x407853E3: giop_send_buffer_append_copy (giop-send-buffer.c:295)
I think I would have been less likely to have missed it if the
"Address 0x4402E83E" line weren't indented. Here's a trivial patch to
de-indent address-info headers if the powers that be agree with me.
--- mac_needs.c 2003-07-24 19:43:11.000000000 -0400
+++ mac_needs.c.new 2003-08-06 02:11:03.000000000 -0400
@@ -226,19 +226,19 @@
switch (ai->akind) {
case Stack:
VG_(message)(Vg_UserMsg,
- " Address 0x%x is on thread %d's stack",
+ "Address 0x%x is on thread %d's stack",
a, ai->stack_tid);
break;
case Unknown:
if (ai->maybe_gcc) {
VG_(message)(Vg_UserMsg,
- " Address 0x%x is just below %%esp. Possibly a bug in GCC/G++",
+ "Address 0x%x is just below %%esp. Possibly a bug in GCC/G++",
a);
VG_(message)(Vg_UserMsg,
- " v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes");
+ "v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes");
} else {
VG_(message)(Vg_UserMsg,
- " Address 0x%x is not stack'd, malloc'd or free'd", a);
+ "Address 0x%x is not stack'd, malloc'd or free'd", a);
}
break;
case Freed: case Mallocd: case UserG: {
@@ -255,7 +255,7 @@
relative = "inside";
}
VG_(message)(Vg_UserMsg,
- " Address 0x%x is %d bytes %s a block of size %d %s",
+ "Address 0x%x is %d bytes %s a block of size %d %s",
a, delta, relative,
ai->blksize,
ai->akind==Mallocd ? "alloc'd"
|
|
From: Steve F. <sf...@re...> - 2003-08-06 17:31:40
|
Greg Hudson wrote: >After rooting through the valgrind source, I discovered that I am >blind, and the address info I coveted is displayed between two partial >stack traces: > >==6579== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) >==6579== at 0x40181C24: vgAllRoadsLeadToRome_writev (vg_intercept.c:108) >==6579== by 0x40181C60: __writev (vg_intercept.c:732) >==6579== by 0x407C311D: (within /usr/lib/liblinc.so.1.0.0) >==6579== by 0x407C32AB: linc_connection_writev (in /usr/lib/liblinc.so.1.0.0) >==6579== Address 0x4402E83E is 10 bytes inside a block of size 2048 alloc'd >==6579== at 0x4002942A: malloc (vg_replace_malloc.c:153) >==6579== by 0x4112F558: g_malloc (in /usr/lib/libglib-2.0.so.0.200.1) >==6579== by 0x4078531E: get_next_indirect (giop-send-buffer.c:273) >==6579== by 0x407853E3: giop_send_buffer_append_copy (giop-send-buffer.c:295) > >I think I would have been less likely to have missed it if the >"Address 0x4402E83E" line weren't indented. Here's a trivial patch to >de-indent address-info headers if the powers that be agree with me. > As a representative of the Powerless That Be, I would rather not see this patch applied as-is. It's already too difficult to scan past the fault records. On the other hand, I also agree with your complaint. Perhaps a half-indent? A special character in the first column? With respect to making fault records easier to scan past, I'd love to see either a newline after a fault record (so you can skip past paragraphs in the editor of your choice), or some fixed searchable text at the beginning of each record. |