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.
