Red Hat Bugzilla – Bug 828640
valgrind defects some use-after-free errors - virsh console
Last modified: 2015-09-27 22:31:28 EDT
Description of problem: valgrind error for change-media and console for now, if there are more commands involved in this error, I 'll track them in this bug. Version-Release number of selected component (if applicable): libvirt-0.9.10-21.el6 How reproducible: always Steps to Reproduce: 1. # valgrind -v --leak-check=full virsh console rhel63 snip... ==15626== 1 errors in context 1 of 11: ==15626== Invalid read of size 4 ==15626== at 0x30336CEA9F: virStreamFree (libvirt.c:15419) ==15626== by 0x40A671: vshRunConsole (console.c:394) ==15626== by 0x4167DE: cmdRunConsole (virsh.c:865) ==15626== by 0x416B9E: cmdConsole (virsh.c:899) ==15626== by 0x413CB4: vshCommandRun (virsh.c:18669) ==15626== by 0x423973: main (virsh.c:20261) ==15626== Address 0x4ea71b0 is 0 bytes inside a block of size 40 free'd ==15626== at 0x4A0595D: free (vg_replace_malloc.c:366) ==15626== by 0x303364F158: virFree (memory.c:310) ==15626== by 0x30336BA64B: virUnrefStream (datatypes.c:1109) ==15626== by 0x30336CEABF: virStreamFree (libvirt.c:15427) ==15626== by 0x40A850: virConsoleShutdown (console.c:103) ==15626== by 0x303364860E: virEventPollRunOnce (event_poll.c:490) ==15626== by 0x30336473B6: virEventRunDefaultImpl (event.c:247) ==15626== by 0x41C231: vshEventLoop (virsh.c:19440) ==15626== by 0x3033658D78: virThreadHelper (threads-pthread.c:161) ==15626== by 0x301A607850: start_thread (in /lib64/libpthread-2.12.so) ==15626== by 0x3019EE767C: clone (in /lib64/libc-2.12.so) 2. # valgrind -v virsh change-media 3 hdc /var/lib/libvirt/images/foo2.img ==16217== 1 errors in context 1 of 12: ==16217== Invalid read of size 1 ==16217== at 0x4A07804: __GI_strlen (mc_replace_strmem.c:284) ==16217== by 0x3019F167F6: xdr_string (in /lib64/libc-2.12.so) ==16217== by 0x3033709E8D: xdr_remote_nonnull_string (remote_protocol.c:31) ==16217== by 0x303370E5CB: xdr_remote_domain_update_device_flags_args (remote_protocol.c:2028) ==16217== by 0x30337197D1: virNetMessageEncodePayload (virnetmessage.c:341) ==16217== by 0x30337135E1: virNetClientProgramCall (virnetclientprogram.c:327) ==16217== by 0x30336F1EFD: callWithFD (remote_driver.c:4586) ==16217== by 0x30336F1F7B: call (remote_driver.c:4607) ==16217== by 0x30336F42F2: remoteDomainUpdateDeviceFlags (remote_client_bodies.h:2865) ==16217== by 0x30336D46E5: virDomainUpdateDeviceFlags (libvirt.c:9457) ==16217== by 0x41AEE8: cmdChangeMedia (virsh.c:15249) ==16217== by 0x413CB4: vshCommandRun (virsh.c:18669) ==16217== Address 0x4ec5e25 is 0 bytes after a block of size 293 alloc'd ==16217== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==16217== by 0x303364F1DB: virAllocN (memory.c:129) ==16217== by 0x41A844: vshPrepareDiskXML (virsh.c:15043) ==16217== by 0x41AECC: cmdChangeMedia (virsh.c:15246) ==16217== by 0x413CB4: vshCommandRun (virsh.c:18669) ==16217== by 0x423973: main (virsh.c:20261) Actual results: defect errors. Expected results: no error. Additional info:
(In reply to comment #0) > Description of problem: > valgrind error for change-media and console for now, if there are more > commands involved in this error, I 'll track them in this bug. It's actually easier for us if you file separate BZs for each. Thanks. -Davea
That's okay for us.:-) Track the issue for change-media in bug 829107.
Should be fixed by commit e3b8808ba
The problem in comment0 step1 is fixed , but i found someone doesn't appear before.I'm not sure whether is a new issue. Something like below Use of uninitialised value of size 8 ==9161== at 0x39D9E04091: numa_node_size64 (in /usr/lib64/libnuma.so.1) ==9161== by 0x39D9E05A48: ??? (in /usr/lib64/libnuma.so.1) ==9161== by 0x39C2E0E534: _dl_init (in /lib64/ld-2.12.so) ==9161== by 0x39C2E00B39: ??? (in /lib64/ld-2.12.so) ==9161== by 0x2: ??? ==9161== by 0x7FF00076E: ??? ==9161== by 0x7FF000774: ??? ==9161== by 0x7FF00077C: ??? See the attachenment for full details
Created attachment 606752 [details] leak-full
(In reply to comment #6) > Created attachment 606752 [details] > leak-full These leaks are irrelevant with libvirt, so you may close this bug IMHO.
(In reply to comment #7) > (In reply to comment #6) > > Created attachment 606752 [details] > > leak-full > > These leaks are irrelevant with libvirt, so you may close this bug IMHO. thanks Accroding comment 5 ,7 . verify this bug
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0276.html