From: Julien Grall <julien.grall@linaro.org>
To: duqi <duqi_2009@163.com>
Cc: "Ian Campbell" <Ian.Campbell@citrix.com>,
"Stefano Stabellini (Xen mainlister)"
<stefano.stabellini@eu.citrix.com>, 宫晓利 <nkgongxl@163.com>,
hdegoede <hdegoede@redhat.com>,
"bjzhang@suse.com" <bjzhang@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: The segmentfault when using xl create domU
Date: Tue, 15 Apr 2014 15:12:36 +0100 [thread overview]
Message-ID: <534D3E54.9060008@linaro.org> (raw)
In-Reply-To: <78496d24.5d.14564c71cc0.Coremail.duqi_2009@163.com>
Hello,
On 04/15/2014 10:45 AM, duqi wrote:
> At 2014-04-15 04:53:41, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>> On Tue, 2014-04-15 at 10:33 +0800, duqi wrote:
>>> Hi there,
>>> We tried to create domU with command "xl -vvv create -d domU_01" and
>>> met the below fault:
>>>
>>> root@linaro-alip:~/domU# xl -vvv create -d domU_01
>>
>> Does this happen if you drop the "-d"?
>>
>> please could you run under gdb and grab a backtrace. Someth8ing like:
>> # gdb --args xl -vvv create -d domU_01
>> (gdb) run
>> ....
>> crash!
>> (gdb) bt
>>
>
> Hi, here is the gdb output:
> Program received signal SIGSEGV, Segmentation fault.
> 0xb6f6bc30 in memcpy (__len=16, __src=0xbefe6e0c, __dest=0x39488)
> at /usr/lib/gcc-cross/arm-linux-gnueabihf/4.7/../../../../arm-linux-gnueabihf/include/bits/string3.h:51
> 51 /usr/lib/gcc-cross/arm-linux-gnueabihf/4.7/../../../../arm-linux-gnueabihf/include/bits/string3.h: No such file or direc.
> (gdb) bt
> #0 0xb6f6bc30 in memcpy (__len=16, __src=0xbefe6e0c, __dest=0x39488)
> at /usr/lib/gcc-cross/arm-linux-gnueabihf/4.7/../../../../arm-linux-gnueabihf/include/bits/string3.h:51
> #1 libxl_list_vm (ctx=ctx@entry=0x33030,
> nb_vm_out=nb_vm_out@entry=0xbeffee30) at libxl.c:689
> #2 0xb6f7b934 in libxl__domain_make (gc=gc@entry=0x393d0,
> info=info@entry=0xbefff040, domid=domid@entry=0xbeffeec0)
> at libxl_create.c:613
> #3 0xb6f7cadc in initiate_domain_create (dcs=0x398a8, egc=0xbeffeec4)
> at libxl_create.c:791
> #4 do_domain_create (ctx=ctx@entry=0x33030,
> d_config=d_config@entry=0xbefff040, domid=domid@entry=0xbeffef80,
> restore_fd=restore_fd@entry=-1,
> checkpointed_stream=checkpointed_stream@entry=0, ao_how=ao_how@entry=0x0,
> aop_console_how=aop_console_how@entry=0x0) at libxl_create.c:1424
> #5 0xb6f7d428 in libxl_domain_create_new (ctx=0x33030,
> d_config=d_config@entry=0xbefff040, domid=domid@entry=0xbeffef80,
> ao_how=ao_how@entry=0x0, aop_console_how=aop_console_how@entry=0x0)
> at libxl_create.c:1449
> #6 0x00017040 in create_domain (dom_info=0xbeffefdc) at xl_cmdimpl.c:2283
> #7 main_create (argc=<optimized out>, argv=<optimized out>)
> at xl_cmdimpl.c:4469
> #8 0x0000db84 in main (argc=3, argv=0xbefff82c) at xl.c:362
> (gdb)
It's a compiler bug. For some reasons gcc doesn't generate the right assembly
when -O1 is specified on the command line. Which version of gcc do you use(4.7.*?)?
Which distribution are you using?
Can you also call disas the crash and copy the output?
Gcc 4.8 doesn't seem to be affected.
FYI, I got this output from 4.7 with Linaro Ubuntu raring (gcc 4.7.3).
0x76f71bd0 <+224>: mov r5, #0
0x76f71bd4 <+228>: mov r4, r5
0x76f71bd8 <+232>: mov r7, r5 <= r7 = r5 = 0
0x76f71bdc <+236>: sub r6, r11, #98304 ; 0x18000
0x76f71be0 <+240>: sub r6, r6, #36 ; 0x24
0x76f71be4 <+244>: mov r9, r5
0x76f71be8 <+248>: str r8, [r12, #-68] ; 0x44
0x76f71bec <+252>: sub r3, r11, #98304 ; 0x18000
0x76f71bf0 <+256>: ldr r0, [r3, #-68] ; 0x44
0x76f71bf4 <+260>: ldrh r1, [r6, r5]
0x76f71bf8 <+264>: mov r2, r9
0x76f71bfc <+268>: bl 0x76f6d6ac
0x76f71c00 <+272>: cmp r0, #0
0x76f71c04 <+276>: bne 0x76f71c50 <libxl_list_vm+352>
0x76f71c08 <+280>: add r8, r7, r7, lsl #2 <= Last time we set r8 = r7 << 2 = 0
0x76f71c0c <+284>: sub r12, r11, #98304 ; 0x18000
0x76f71c10 <+288>: str r8, [r12, #-56] ; 0x38
0x76f71c14 <+292>: ldr r3, [r12, #-60] ; 0x3c
0x76f71c18 <+296>: add lr, r3, r8, lsl #2
0x76f71c1c <+300>: add r12, r4, r4, lsl #1
0x76f71c20 <+304>: add r12, r6, r12, lsl #5
0x76f71c24 <+308>: add r12, r12, #76 ; 0x4c
0x76f71c28 <+312>: ldm r12!, {r0, r1, r2, r3}
0x76f71c2c <+316>: mov r12, r8
=> 0x76f71c30 <+320>: ldr r8, [r8, #-60] ; 0x3c <= r8 (=0) is dereferenced
Regards,
--
Julien Grall
next prev parent reply other threads:[~2014-04-15 14:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 2:33 The segmentfault when using xl create domU duqi
2014-04-15 8:53 ` Ian Campbell
2014-04-15 9:45 ` duqi
2014-04-15 14:12 ` Julien Grall [this message]
2014-04-15 22:07 ` Wei Huang
2014-04-16 9:21 ` Ian Campbell
2014-04-16 15:50 ` Wei Huang
2014-04-16 15:56 ` Julien Grall
2014-04-16 9:12 ` duqi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=534D3E54.9060008@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=bjzhang@suse.com \
--cc=duqi_2009@163.com \
--cc=hdegoede@redhat.com \
--cc=nkgongxl@163.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).