Re: [Qemu-devel] weird qdev error

[Michael S. Tsirkin]

On Mon, Feb 13, 2012 at 02:17:35AM +0200, Michael S. Tsirkin wrote:
> On Sun, Feb 12, 2012 at 02:19:19PM -0600, Anthony Liguori wrote:
> > On 02/12/2012 02:15 PM, Michael S. Tsirkin wrote:
> > >On Sun, Feb 12, 2012 at 02:04:29PM -0600, Anthony Liguori wrote:
> > >>On 02/12/2012 11:57 AM, Michael S. Tsirkin wrote:
> > >>>On Sun, Feb 12, 2012 at 11:38:24AM -0600, Anthony Liguori wrote:
> > >>>>From: Anthony Liguori<address@hidden>
> > >>>>Date: Sun, 12 Feb 2012 11:36:24 -0600
> > >>>>Subject: [PATCH] device_add: don't add a /peripheral link until init is 
> > >>>>complete
> > >>>>
> > >>>>Otherwise we end up with a dangling reference which causes qdev_free() 
> > >>>>to fail.
> > >>>>
> > >>>>Reported-by: Michael Tsirkin<address@hidden>
> > >>>>Signed-off-by: Anthony Liguori<address@hidden>
> > >>>
> > >>>This handles the option parsing but what about hotplug
> > >>>failures (when bus->hotplug returns an error)?
> > >>
> > >>Sorry, I don't follow.
> > >>
> > >>The assert you reported was that object_free() noted a reference
> > >>count of !0 which indicates something else was holding the reference
> > >>to the object.  In this case, it was the child link in /peripheral.
> > >>
> > >>By delaying creating the link in /peripheral, we eliminate the problem 
> > >>completely.
> > >
> > >Th other problem was internal in pci which calls ->hostplug
> > >during initialization. This doesn't seem affected?
> > >But I didn't try, maybe I misundertand.
> > 
> > Yeah, from qdev's perspective it's all just init failing.  hotplug
> > is entirely a PCI concept.
> > 
> > >
> > >>BTW, the explicit calls to do_pci_unregister are redundant.
> > >>finalize() will be called during cleanup which means exit() will be
> > >>invoked (which already calls do_pci_unregister).  I'm not sure why
> > >>this isn't failing more aggressively but it looks clearly wrong to
> > >>me.
> > >>
> > >>Regards,
> > >>
> > >>Anthony Liguori
> > >
> > >Me too. Want to try to drop them?
> > 
> > Yeah, I'll make this a two patch series.
> > 
> > Regards,
> > 
> > Anthony Liguori
> 
> 
> I also see this:
> 
> device_add virtio-net-pci,netdev=foo,mac=52:54:00:12:34:56,id=bla
> device_del bla
> *** glibc detected *** /home/mst/qemu-test/bin/qemu-system-x86_64:
> corrupted double-linked list: 0x00007fae434565a0 ***
> 
> Am I alone?
> 
> 


Tried some tracing:  I set breakpoint at g_free
and gave the device_del command.

(gdb) b g_free
Breakpoint 3 at 0x7ffff73f55b0
(gdb) c
Continuing.

Program received signal SIGTSTP, Stopped (user).
[Switching to Thread 0x7fffaf1a3700 (LWP 22749)]
0x00007ffff6ae074b in pthread_cond_timedwait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
(gdb) c
Continuing.

Program received signal SIGTSTP, Stopped (user).
[Switching to Thread 0x7ffff4b28700 (LWP 22727)]
0x00007ffff6ae03cc in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
(gdb) continue
Continuing.

Program received signal SIGTSTP, Stopped (user).
[Switching to Thread 0x7ffff7cb3700 (LWP 22712)]
0x00007ffff604c383 in select () from /lib64/libc.so.6
(gdb) continue
Continuing.
[Thread 0x7fffaf1a3700 (LWP 22749) exited]


Breakpoint 3, 0x00007ffff73f55b0 in g_free () from /lib64/libglib-2.0.so.0
(gdb) continue
Continuing.
(qemu) device_del bla

Breakpoint 3, 0x00007ffff73f55b0 in g_free () from /lib64/libglib-2.0.so.0
(gdb) where
#0  0x00007ffff73f55b0 in g_free () from /lib64/libglib-2.0.so.0
#1  0x00007ffff7ec1d60 in monitor_parse_command (mon=0x7ffff8b207a0, 
    cmdline=<value optimized out>, qdict=0x7ffff9161660)
    at /home/mst/scm/qemu/monitor.c:3724
#2  0x00007ffff7ec2684 in handle_user_command (mon=0x7ffff8b207a0, cmdline=
    0x7ffff8c86a30 "device_del bla") at /home/mst/scm/qemu/monitor.c:3803
#3  0x00007ffff7ec2b6e in monitor_command_cb (mon=0x7ffff8b207a0, 
    cmdline=<value optimized out>, opaque=<value optimized out>)
    at /home/mst/scm/qemu/monitor.c:4436
#4  0x00007ffff7e463ed in readline_handle_byte (rs=0x7ffff8c86a30, 
    ch=<value optimized out>) at readline.c:370
#5  0x00007ffff7ec28b8 in monitor_read (opaque=<value optimized out>, buf=
    0x7fffffffce20 "\r\023\f\366\377\177", size=1) at 
/home/mst/scm/qemu/monitor.c:4422
#6  0x00007ffff7e313bb in qemu_chr_be_write (opaque=0x7ffff8b0ca00) at 
qemu-char.c:163
#7  fd_chr_read (opaque=0x7ffff8b0ca00) at qemu-char.c:587
#8  0x00007ffff7d7c967 in qemu_iohandler_poll (readfds=0x7fffffffdfb0, writefds=
    0x7fffffffdf30, xfds=<value optimized out>, ret=<value optimized out>)
    at iohandler.c:121
#9  0x00007ffff7e1085f in main_loop_wait (nonblocking=<value optimized out>)
    at main-loop.c:464
#10 0x00007ffff7e09284 in main_loop (argc=<value optimized out>, 
    argv=<value optimized out>, envp=<value optimized out>)
    at /home/mst/scm/qemu/vl.c:1482
#11 main (argc=<value optimized out>, argv=<value optimized out>, 
    envp=<value optimized out>) at /home/mst/scm/qemu/vl.c:3525
(gdb) frame 1
#1  0x00007ffff7ec1d60 in monitor_parse_command (mon=0x7ffff8b207a0, 
    cmdline=<value optimized out>, qdict=0x7ffff9161660)
    at /home/mst/scm/qemu/monitor.c:3724
3724            g_free(key);
(gdb) p key
$1 = 0x7ffff9166820 "id"
(gdb) continue
Continuing.

Breakpoint 3, 0x00007ffff73f55b0 in g_free () from /lib64/libglib-2.0.so.0
(gdb) where
#0  0x00007ffff73f55b0 in g_free () from /lib64/libglib-2.0.so.0
#1  0x00007ffff7e42fd4 in object_property_del (obj=0x7ffff8ca79d0, 
    name=<value optimized out>, errp=<value optimized out>) at qom/object.c:629
#2  0x00007ffff7e4308d in object_property_del_child (obj=0x7ffff9123e50)
    at qom/object.c:310
#3  object_unparent (obj=0x7ffff9123e50) at qom/object.c:318
#4  0x00007ffff7de0a0d in pci_unplug_device (qdev=<value optimized out>)
    at /home/mst/scm/qemu/hw/pci.c:1521
#5  0x00007ffff7ec26b5 in handle_user_command (mon=0x7ffff8b207a0, 
    cmdline=<value optimized out>) at /home/mst/scm/qemu/monitor.c:3813
#6  0x00007ffff7ec2b6e in monitor_command_cb (mon=0x7ffff8b207a0, 
    cmdline=<value optimized out>, opaque=<value optimized out>)
    at /home/mst/scm/qemu/monitor.c:4436
#7  0x00007ffff7e463ed in readline_handle_byte (rs=0x7ffff8c86a30, 
    ch=<value optimized out>) at readline.c:370
#8  0x00007ffff7ec28b8 in monitor_read (opaque=<value optimized out>, buf=
    0x7fffffffce20 "\r\023\f\366\377\177", size=1) at 
/home/mst/scm/qemu/monitor.c:4422
#9  0x00007ffff7e313bb in qemu_chr_be_write (opaque=0x7ffff8b0ca00) at 
qemu-char.c:163
#10 fd_chr_read (opaque=0x7ffff8b0ca00) at qemu-char.c:587
#11 0x00007ffff7d7c967 in qemu_iohandler_poll (readfds=0x7fffffffdfb0, writefds=
    0x7fffffffdf30, xfds=<value optimized out>, ret=<value optimized out>)
    at iohandler.c:121
#12 0x00007ffff7e1085f in main_loop_wait (nonblocking=<value optimized out>)
    at main-loop.c:464
#13 0x00007ffff7e09284 in main_loop (argc=<value optimized out>, 
    argv=<value optimized out>, envp=<value optimized out>)
    at /home/mst/scm/qemu/vl.c:1482
#14 main (argc=<value optimized out>, argv=<value optimized out>, 
---Type <return> to continue, or q <return> to quit---
    envp=<value optimized out>) at /home/mst/scm/qemu/vl.c:3525
(gdb) frame 1
#1  0x00007ffff7e42fd4 in object_property_del (obj=0x7ffff8ca79d0, 
    name=<value optimized out>, errp=<value optimized out>) at qom/object.c:629
629         g_free(prop->name);
(gdb) p prop->name
$2 = (gchar *) 0x7ffff9164510 "bla"
(gdb) continue
Continuing.

Breakpoint 3, 0x00007ffff73f55b0 in g_free () from /lib64/libglib-2.0.so.0
(gdb) frame 1
#1  0x00007ffff7e42fdd in object_property_del (obj=0x7ffff8ca79d0, 
    name=<value optimized out>, errp=<value optimized out>) at qom/object.c:630
630         g_free(prop->type);
(gdb) p prop->type
$3 = (gchar *) 0x7ffff9164580 "child<virtio-net-pci>"
(gdb) continue
Continuing.

Breakpoint 3, 0x00007ffff73f55b0 in g_free () from /lib64/libglib-2.0.so.0
(gdb) frame 1
#1  0x00007ffff7e4308d in object_property_del_child (obj=0x7ffff9123e50)
    at qom/object.c:310
310                 object_property_del(obj, prop->name, errp);
(gdb) p prop->name
$4 = (gchar *) 0x7ffff9164510 "\020h\026\371\377\177"

>>>>>>>>>>>>>>>>>>>>>>>>>>>>
It seems clear that there is at least a use after free
here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>

This is not an immediate source of the crash, however.

-- 
MST