Bug 864899 - valgrind reports "Syscall param write(buf) points to uninitialised byte(s)" when event contains a log message
valgrind reports "Syscall param write(buf) points to uninitialised byte(s)" w...
Status: CLOSED CURRENTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libguestfs (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard W.M. Jones
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-10 07:04 EDT by Richard W.M. Jones
Modified: 2012-11-15 11:22 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-15 11:22:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2012-10-10 07:04:32 EDT
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 07:24:18 EDT
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 07:28:24 EDT
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 17:34:20 EDT
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 11:22:14 EST
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.