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<aligu...@us.ibm.com>
> > >>>>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<m...@redhat.com>
> > >>>>Signed-off-by: Anthony Liguori<aligu...@us.ibm.com>
> > >>>
> > >>>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
