[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:485ret = 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |