WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] libxl: xl create segfaults

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] libxl: xl create segfaults
From: Christoph Egger <Christoph.Egger@xxxxxxx>
Date: Thu, 23 Sep 2010 12:27:29 +0200
Delivery-date: Thu, 23 Sep 2010 03:47:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.10
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

<Prev in Thread] Current Thread [Next in Thread>