Bug 864899 - valgrind reports "Syscall param write(buf) points to uninitialised byte(s)" when event contains a log message
Summary: valgrind reports "Syscall param write(buf) points to uninitialised byte(s)" w...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-10 11:04 UTC by Richard W.M. Jones
Modified: 2012-11-15 16:22 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-11-15 16:22:25 UTC
Embargoed:


Attachments (Terms of Use)

Description Richard W.M. Jones 2012-10-10 11:04:32 UTC
Description of problem:

Don't know if this is real or not, but valgrind reports:

==1404== Syscall param write(buf) points to uninitialised byte(s)
==1404==    at 0x30D0AE4C30: __write_nocancel (in /usr/lib64/libc-2.16.so)
==1404==    by 0x30D0A76172: _IO_file_write@@GLIBC_2.2.5 (in /usr/lib64/libc-2.16.so)
==1404==    by 0x30D0A76051: new_do_write (in /usr/lib64/libc-2.16.so)
==1404==    by 0x30D0A77774: _IO_do_write@@GLIBC_2.2.5 (in /usr/lib64/libc-2.16.so)
==1404==    by 0x30D0A769C0: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib64/libc-2.16.so)
==1404==    by 0x30D0A6C38C: fwrite (in /usr/lib64/libc-2.16.so)
==1404==    by 0x4C8E8F9: guestfs___call_callbacks_message (events.c:111)
==1404==    by 0x4CA3D57: read_log_message_or_eof (proto.c:222)
==1404==    by 0x4CA4BF9: guestfs___recv_from_daemon (proto.c:528)
==1404==    by 0x4CA0579: launch_libvirt (launch-libvirt.c:373)
==1404==    by 0x4C2BD7D: guestfs_launch (actions.c:1499)
==1404==    by 0x400A07: main (test-debug-to-file.c:85)
==1404==  Address 0x4ee1215 is not stack'd, malloc'd or (recently) free'd

I modified the guestfs___call_callbacks_message function so
it printed every buffer that goes through that function.  However
none of the buffer pointers that were printed looked as if they
could contain the address 0x4ee1215.

Therefore my conclusion is that the failing address is an internal
glibc FILE* buffer.

The codepath simply copies the buffer pointer and buffer length
from the read(2) system call through to the fwrite(3) call.  I
cannot see how that would cause an uninitialized byte.

Version-Release number of selected component (if applicable):

libguestfs 1.19.49
glibc-2.16-3.fc18.x86_64

How reproducible:

Not 100%, but running test-debug-to-file through valgrind
shows the error maybe 25% of the time.

Steps to Reproduce:
1. make extra-tests

Comment 1 Richard W.M. Jones 2012-10-10 11:24:18 UTC
It looks like updating to glibc 2.16-17 has fixed this
(or made it occur so rarely that my repeated testing
cannot find it).

Comment 2 Richard W.M. Jones 2012-10-10 11:28:24 UTC
Wrong!  The bug happened again:

==334== Syscall param write(buf) points to uninitialised byte(s)
==334==    at 0x5403590: __write_nocancel (syscall-template.S:81)
==334==    by 0x5394602: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1283)
==334==    by 0x53944E1: new_do_write (fileops.c:538)
==334==    by 0x5395C04: _IO_do_write@@GLIBC_2.2.5 (fileops.c:511)
==334==    by 0x5394E50: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1354)
==334==    by 0x538A6DC: fwrite (iofwrite.c:43)
==334==    by 0x4EAF8A2: guestfs___call_callbacks_message (events.c:108)
==334==    by 0x4EC4CB7: read_log_message_or_eof (proto.c:222)
==334==    by 0x4EC5B59: guestfs___recv_from_daemon (proto.c:528)
==334==    by 0x4EC14D9: launch_libvirt (launch-libvirt.c:373)
==334==    by 0x4E4CD7D: guestfs_launch (actions.c:1499)
==334==    by 0x400A07: main (test-debug-to-file.c:85)
==334==  Address 0x4022214 is not stack'd, malloc'd or (recently) free'd

I strongly suspect this is a glibc bug.

Comment 3 Richard W.M. Jones 2012-10-13 21:34:20 UTC
And again:
==1548== Syscall param write(buf) points to uninitialised byte(s)
==1548==    at 0x3916CE5590: __write_nocancel (syscall-template.S:81)
==1548==    by 0x3916C76602: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1283)
==1548==    by 0x3916C764E1: new_do_write (fileops.c:538)
==1548==    by 0x3916C77C04: _IO_do_write@@GLIBC_2.2.5 (fileops.c:511)
==1548==    by 0x3916C76E50: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1354)
==1548==    by 0x3916C6C6DC: fwrite (iofwrite.c:43)
==1548==    by 0x4C8F462: guestfs___call_callbacks_message (events.c:108)
==1548==    by 0x4CA4FF7: read_log_message_or_eof (proto.c:222)
==1548==    by 0x4CA5E99: guestfs___recv_from_daemon (proto.c:528)
==1548==    by 0x4CA1089: launch_libvirt (launch-libvirt.c:372)
==1548==    by 0x4C2C03D: guestfs_launch (actions.c:1499)
==1548==    by 0x400A07: main (test-debug-to-file.c:85)
==1548==  Address 0x4ee33ac is not stack'd, malloc'd or (recently) free'd

Comment 4 Richard W.M. Jones 2012-11-15 16:22:14 UTC
I'm going to say, tentatively, that this bug has fixed
itself.  At least, I've been using the new 'make check-valgrind'
rule extensively and have not seen this happen recently.


Note You need to log in before you can comment on or make changes to this bug.