Red Hat Bugzilla – Bug 864899
valgrind reports "Syscall param write(buf) points to uninitialised byte(s)" when event contains a log message
Last modified: 2012-11-15 11:22:40 EST
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
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).
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.
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
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.