[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start



Il 02/04/2014 18:03, Anthony PERARD ha scritto:
On Wed, Apr 02, 2014 at 01:13:31PM +0200, Fabio Fantoni wrote:
- if you posted qemu's backtrace at the sigsegv.
I tried to use gdb following this old post:
https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02575.html
but with same changes:

/usr/lib/xen/bin# vi qemu-system-i386
#!/bin/sh
exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386.bak "$@"

gdb /usr/lib/xen/bin/qemu-system-i386.bak
target remote localhost:1234

This command with gdb on qemu fails:
xl -vvv create /etc/xen/wheezy.cfg
...
libxl: error: libxl_dm.c:1378:device_model_spawn_outcome: domain 13 device
model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1207:domcreate_devmodel_started: device model
did not start: -3
libxl: debug: libxl_dm.c:1485:kill_device_model: Device Model signaled
...

the dom0 syslog show segfault also in this case and the qemu log is
different on first lines (probably for gdbserver):
less /var/log/xen/qemu-dm-wheezy.log
Process /usr/lib/xen/bin/qemu-system-i386.bak created; pid = 8238
Listening on port 1234
Remote debugging from host 127.0.0.1
xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 =
Invalid argument): Internal error
xen be: qdisk-51712: xc_gnttab_set_max_grants failed: Invalid argument


gdb on xl create show:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb)

(gdb) bt full
#0  0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
No symbol table info available.
#1  0x0000000000000013 in ?? ()
No symbol table info available.
#2  0x00007fffffffe871 in ?? ()
No symbol table info available.
#3  0x00007fffffffe897 in ?? ()
No symbol table info available.
#4  0x00007fffffffe8a2 in ?? ()
No symbol table info available.
#5  0x00007fffffffe8a5 in ?? ()
No symbol table info available.
#6  0x00007fffffffe8ae in ?? ()
No symbol table info available.
#7  0x00007fffffffe8ef in ?? ()
No symbol table info available.
#8  0x00007fffffffe8f4 in ?? ()
No symbol table info available.
#9  0x00007fffffffe913 in ?? ()
No symbol table info available.
#10 0x00007fffffffe91f in ?? ()
No symbol table info available.
#11 0x00007fffffffe92b in ?? ()
No symbol table info available.
#12 0x00007fffffffe931 in ?? ()
---Type <return> to continue, or q <return> to quit---

the qemu include debug and is not stripped:
file /usr/lib/xen/bin/qemu-system-i386.bak
/usr/lib/xen/bin/qemu-system-i386.bak: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
2.6.26, BuildID[sha1]=0x5aa043b5524d74d166ead62527343080384d586b, not
stripped
and I also tried:
aptitude install libc6-dbg
but same result.

I not understand what I missed for correct xl create and/or gdb
informations.
Can someone help me please?
Using gdb on qemu is not easy, you need to be quick.

When you "xl create", you have about 10 second to start gdb on qemu,
otherwise, xl will fail to create a guest.

So I advise you to start "gdb /usr/lib/xen/bin/qemu-system-i386.bak" in
a second terminal, write "target remote localhost:1234" BUT not Enter,
to keep the command ready to run.
Then, start "xl create" and imediatly, run the "target" command in gdb
and "c" (for continue) which will start qemu.

That should help you reach the point where you can get the backtrace,
after the segv.


Thanks for your reply.
I following your istructions, after "c" xl create finish.
gdb show:
(gdb) C
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000055555584b4c1 in qemu_input_event_send (src=0x0, evt=0x55555630a420)
    at ui/input.c:146
146         s->handler->event(s->dev, src, evt);

(gdb) bt full
#0 0x000055555584b4c1 in qemu_input_event_send (src=0x0, evt=0x55555630a420)
    at ui/input.c:146
        s = 0x0
#1 0x000055555584baef in qemu_input_queue_rel (src=0x0, axis=INPUT_AXIS_X,
    value=1) at ui/input.c:272
        evt = 0x55555630a420
#2 0x0000555555871043 in pointer_event (vs=0x55555630a4c0, button_mask=0,
    x=478, y=186) at ui/vnc.c:1531
        bmap = {1, 2, 4, 8, 16}
        con = 0x0
        width = 640
        height = 480
#3  0x0000555555872c00 in protocol_client_msg (vs=0x55555630a4c0,
    data=0x5555562fe420 "\005", len=6) at ui/vnc.c:2139
        i = 1446028480
        limit = 22063
        vd = 0x7ffff7eb6010
#4  0x0000555555870861 in vnc_client_read (opaque=0x55555630a4c0)
    at ui/vnc.c:1389
        len = 6
        ret = 6
        vs = 0x55555630a4c0
        ret = 6
#5 0x00005555557cd5cc in qemu_iohandler_poll (pollfds=0x5555562e6a00, ret=1)
    at iohandler.c:143
---Type <return> to continue, or q <return> to quit---
        revents = 1
        pioh = 0x5555562fa780
        ioh = 0x5555562f5560
#6 0x00005555557ce678 in main_loop_wait (nonblocking=0) at main-loop.c:485
        ret = 1
        timeout = 4294967295
        timeout_ns = 79570735
#7  0x000055555587a070 in main_loop () at vl.c:2051
        nonblocking = false
        last_io = 1
#8  0x0000555555881a4a in main (argc=19, argv=0x7fffffffe5f8,
    envp=0x7fffffffe698) at vl.c:4507
        i = 64
        snapshot = 0
        linux_boot = 0
        icount_option = 0x0
        initrd_filename = 0x0
        kernel_filename = 0x0
        kernel_cmdline = 0x555555a1a464 ""
        boot_order = 0x0
        ds = 0x5555562f34a0
        cyls = 0
        heads = 0
        secs = 0
        translation = 0
---Type <return> to continue, or q <return> to quit---
        hda_opts = 0x0
        opts = 0x0
        machine_opts = 0x5555562e6600
        olist = 0x555555dffe00
        optind = 19
        optarg = 0x7fffffffe969 "1025"
        loadvm = 0x0
        machine_class = 0x5555562d6d50
        machine = 0x555555e0d2c0
        cpu_model = 0x0
        vga_model = 0x0
        qtest_chrdev = 0x0
        qtest_log = 0x0
        pid_file = 0x0
        incoming = 0x0
        show_vnc_port = 0
        defconfig = true
        userconfig = true
        log_mask = 0x0
        log_file = 0x0
        mem_trace = {malloc = 0x55555587d902 <malloc_and_trace>,
          realloc = 0x55555587d95a <realloc_and_trace>,
free = 0x55555587d9c1 <free_and_trace>, calloc = 0, try_malloc = 0,
          try_realloc = 0}
        trace_events = 0x0
---Type <return> to continue, or q <return> to quit---
        trace_file = 0x0
        __func__ = "main"
        args = {machine = 0x555555e0d2c0, ram_size = 1074790400,
          boot_order = 0x0, kernel_filename = 0x0,
          kernel_cmdline = 0x555555a1a464 "", initrd_filename = 0x0,
          cpu_model = 0x0}
(gdb)

Seems that do segfault when I connect to vnc or spice, in the test of this backtrace after connect to vnc, spice and other things of my patches are disabled, so do not think it is a problem caused by my patches.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.