Hi!
'xl create' crashes due to stack corruption.
This is a backtrace where everything seems to be fine. Have
a look at the 'fmt' and 'dir' arguments.
(gdb) bt
#0 0x00007f7ffc03f4e2 in vsnprintf () from /usr/lib/libc.so.12
#1 0x00007f7ffd416ab5 in libxl__sprintf (gc=0x7f7fffffd220,
fmt=0x7f7ffd41c467 "%s/%s") at libxl_internal.c:112
#2 0x00007f7ffd415258 in libxl__xs_writev (gc=0x7f7fffffd220, t=9,
dir=0x7f7ffdb010e0 "/vm/46ac5197-ecc6-df11-bcf6-00e081806fbe",
kvs=0x7f7ffdb1f0b0) at libxl_xshelp.c:82
#3 0x00007f7ffd40f477 in libxl_create_device_model (ctx=0x6179a0,
info=0x7f7fffffd470, disks=0x7f7ffdb014d0, num_disks=1,
vifs=0x7f7ffdb16070,
num_vifs=1, starting_r=0x7f7fffffd440) at libxl.c:1723
#4 0x000000000040f6c1 in create_domain (dom_info=0x7f7fffffd6f0)
at xl_cmdimpl.c:1458
#5 0x00000000004104b3 in main_create (argc=2, argv=0x7f7fffffdbc8)
at xl_cmdimpl.c:3214
#6 0x0000000000404ad2 in main (argc=3, argv=0x7f7fffffdbc8) at xl.c:79
This is a backtrace where the stack corruption happened. Have
a look at the 'fmt' and 'dir' arguments.
(gdb) cont
Continuing.
Watchpoint 3: fmt
Old value = 0x7f7ffd41c467 "%s/%s"
New value = 0x7f7fffffce30 "\020"
(gdb) bt
#0 0x00007f7ffc03f553 in vsnprintf () from /usr/lib/libc.so.12
#1 0x00007f7ffd416ab5 in libxl__sprintf (gc=0x7f7fffffd220,
fmt=0x7f7fffffce30 "\020") at libxl_internal.c:112
#2 0x00007f7ffd415258 in libxl__xs_writev (gc=0x7f7fffffd220, t=9,
dir=0x7f7ffdb010e0 "/vm/46ac5197-ecc6-df11-bcf6-00e081806fbe",
kvs=0x7f7ffdb1f0b0) at libxl_xshelp.c:82
#3 0x00007f7ffd40f477 in libxl_create_device_model (ctx=0x6179a0,
info=0x7f7fffffd470, disks=0x7f7ffdb014d0, num_disks=1,
vifs=0x7f7ffdb16070,
num_vifs=1, starting_r=0x7f7fffffd440) at libxl.c:1723
#4 0x000000000040f6c1 in create_domain (dom_info=0x7f7fffffd6f0)
at xl_cmdimpl.c:1458
#5 0x00000000004104b3 in main_create (argc=2, argv=0x7f7fffffdbc8)
at xl_cmdimpl.c:3214
#6 0x0000000000404ad2 in main (argc=3, argv=0x7f7fffffdbc8) at xl.c:79
This is a backtrace where the stack corruption caused a segfault. Have
a look at the 'fmt' and 'dir' arguments.
(gdb) bt
#0 0x00007f7ffc0cac0e in __vfprintf_unlocked () from /usr/lib/libc.so.12
#1 0x00007f7ffc03f55b in vsnprintf () from /usr/lib/libc.so.12
#2 0x00007f7ffd416ab5 in libxl__sprintf (gc=0x7f7fffffd220,
fmt=0x7265776f705f6e6f <Address 0x7265776f705f6e6f out of bounds>)
at libxl_internal.c:112
#3 0x00007f7ffd415258 in libxl__xs_writev (gc=0x7f7fffffd220, t=13,
dir=0x7f7ffdb010e0 "/vm/46ac5197-ecc6-df11-bcf6-00e081806fbe",
kvs=0x7f7ffdb1f0b0) at libxl_xshelp.c:82
#4 0x00007f7ffd40f477 in libxl_create_device_model (ctx=0x6179a0,
info=0x7f7fffffd470, disks=0x7f7ffdb014d0, num_disks=1,
vifs=0x7f7ffdb16070,
num_vifs=1, starting_r=0x7f7fffffd440) at libxl.c:1723
#5 0x000000000040f6c1 in create_domain (dom_info=0x7f7fffffd6f0)
at xl_cmdimpl.c:1458
#6 0x00000000004104b3 in main_create (argc=2, argv=0x7f7fffffdbc8)
at xl_cmdimpl.c:3214
#7 0x0000000000404ad2 in main (argc=3, argv=0x7f7fffffdbc8) at xl.c:79
The crash is reproducable. The 'dir' argument always contains the uuid string
when the stack corruption happens. And it seems that the 'dir' string
is the longest when it contains the uuid string.
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home