Bug 864899

Summary:	valgrind reports "Syscall param write(buf) points to uninitialised byte(s)" when event contains a log message
Product:	[Community] Virtualization Tools	Reporter:	Richard W.M. Jones <rjones>
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	dyasny, mbooth
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-11-15 16:22:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.