Re: [Xen-devel] Why `xl restore` runs OK by shell but running on gdb encounter an segmentation fault?

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Please don't drop the list. I've added it back.


On Tue, 2012-07-31 at 09:58 +0100, éç wrote:
> 
> 
> On Tue, Jul 31, 2012 at 4:41 PM, Ian Campbell
> <Ian.Campbell@xxxxxxxxxx> wrote:
>         On Tue, 2012-07-31 at 09:16 +0100, éç wrote:
>         >
>         >
>         > On Tue, Jul 31, 2012 at 2:55 PM, éç <aware.why@xxxxxxxxx>
>         wrote:
>         >         Hi all,
>         >             I paste below the running info of `gdb xl`
>         >         Program received signal SIGSEGV, Segmentation fault.
>         >         0x000000000040a8a3 in create_domain
>         (dom_info=0x7fffffffe4f0)
>         >         at xl_cmdimpl.c:1432
>         >         (gdb) bt
>         >         #0  0x000000000040a8a3 in create_domain
>         >         (dom_info=0x7fffffffe4f0) at xl_cmdimpl.c:1432
>         >         #1  0x000000000040f938 in main_restore (argc=2,
>         >         argv=0x7fffffffe6b8) at xl_cmdimpl.c:2932
>         >         #2  0x000000000040508b in main (argc=2,
>         argv=0x7fffffffe6b8)
>         >         at xl.c:141
>         >         (gdb) show args
>         >         Argument list to give program being debugged when it
>         is
>         >         started is "-v restore ./xp101.save".
>         >
>         >
>         >             Actually, in the shell I could run `xl -v
>         >         restore ./xp101.save` successfully.
>         >             Did anyone encounter the same wired problem?
>         >
>         >
>         >         thanks in advance
>         >
>         > I need to dig into xl  by gdb,  could anyone kind-hearted
>         help me get
>         >  through this problem...
>         
>         
>         You need to be more patient -- you left around 80 minutes
>         between your
>         original mail and this ping. Remember that not everyone is
>         awake and
>         online at the same times as you are, nor can they be expected
>         to drop
>         everything to reply to your mail.
>         
>         I'm afraid that "gdb --args xl -v restore SAVED" works fine
>         for me.
>         
>         I presume that running under gdb perturbs timings or memory
>         layout etc
>         to expose a previously latent bug.
>         
>         gdb has given you the line numbers of where the segmentation
>         fault has
>         occurred -- why don't you investigate further?
>         
>         Ian.
>         
> I investigated it and observed the local variables info, the line 1432
> is not likely to cause SIGSEGV  in theory because `xmalloc` works well
> and config_data\optdata_here\config_len was right.
> But after xmalloc, application received SIGSEGV while config_data had
> a valid value as (void *) 0x622e10.
> 1426        if (OPTDATA_LEFT) {                                               
>                   
> 1427            fprintf(stderr, " Savefile contains xl domain config\n");     
>                                                                               
>                                                                               
>   
> 1428            WITH_OPTDATA(4, {                                             
>                                                                               
>                                                                               
>   
> 1429                memcpy(u32buf.b, optdata_here, 4);                        
>                                                                               
>                                                                               
>   
> 1430                config_len = u32buf.u32;                                  
>                                                                               
>                                                                               
>   
> 1431            });                                                           
>                                                                               
>                                                                               
>   
> 1432            WITH_OPTDATA(config_len, {                                    
>                                                                               
>                                                                               
>   
> 1433                config_data = xmalloc(config_len);                        
>                                                                               
>                                                                               
>   
> 1434                memcpy(config_data, optdata_here, config_len);            
>                                                                               
>                                                                               
>   

Is "optdata_here" valid too?

Have you checked the values of all the local variables with "print
<var>"?

You can use the "disas" to print the assembly code and find the exact
instruction which caused the fault. That might give a clue as to which
variable was invalid. You might also need to add some prints of
variables etc to check that they are ok.

Which version of Xen is this happening with? These line numbers do not
correspond at all to the head version (I have this stuff at line 169x)
and I don't see anything recently which added 200+ lines to xl_cmdimpl.c

> 1435            });                                                           
>                                                                               
>                                                                               
>   
> 1436        }          



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel