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

[Fabio Fantoni <fabio.fantoni@m2r.biz>]

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.