[Crash-utility] [patch]Crash can't process xen dump core files larger that 4GB.

[Dave Anderson]

----- "xiaowei hu" <xiaowei.hu at oracle.com> wrote:

> Hi all,
> 
> There is a bug when using crash to process the xen domU dump core that
> larger that 4GB(it is found at processing a 10GB guest core dump file).
> crash reporting this errors:
> crash: cannot find mfn 8392757 (0x801035) in page index               
>  
> 
> crash: cannot read/find cr3 page
> 
> this is caused by a var overflow,in the structure of 
> typedef struct xc_core_header { 
>      unsigned int xch_magic; 
>      unsigned int xch_nr_vcpus; 
>      unsigned int xch_nr_pages; 
>      unsigned int xch_ctxt_offset; 
>      unsigned int xch_index_offset; 
>      unsigned int xch_pages_offset; 
> } xc_core_header_t;
> 
> the xch_ctxt_offset,xch_index_offset and xch_pages_offset mean the
> offsets in the core dump file , when it is defined as unsingend
> long ,that means the file can't be more that 4GB,so when processing with
> core dump files that more than 4GB may have error (I encountered
> overflow on that 10GB file),so changing those offset vars to unsigned
> long ,make sure crash can seek to the right position.
> btw,please reply directly to me ,I am not in the mail list.
> 
> 
> Signed-off-by: Xiaowei Hu <xiaowei.hu at oracle.com>
> 
> 
> diff -up crash-5.0.0/xendump.h.org crash-5.0.0/xendump.h
> --- crash-5.0.0/xendump.h.org	2010-02-04 03:48:04.000000000 +0800
> +++ crash-5.0.0/xendump.h	2010-02-04 05:41:27.000000000 +0800
> @@ -28,9 +28,9 @@ typedef struct xc_core_header {
>      unsigned int xch_magic;
>      unsigned int xch_nr_vcpus;
>      unsigned int xch_nr_pages;
> -    unsigned int xch_ctxt_offset;
> -    unsigned int xch_index_offset;
> -    unsigned int xch_pages_offset;
> +    unsigned long xch_ctxt_offset;
> +    unsigned long xch_index_offset;
> +    unsigned long xch_pages_offset;
>  } xc_core_header_t;
>  
>  struct pfn_offset_cache {

First question -- are you saying that the change above works for you?

And second -- in your dumpfile, even with 10GB of memory, wouldn't
the base offset value of all three indexes still fit well below
the 4GB mark?

The xc_core_header in crash is a copy of that found in "tools/libxc/xenctrl.h",
and is presumptively the beginning/header of the dumpfile.  And so making the
wholesale change above breaks all earlier (?) versions.  

But what is confusing is that the latest/final version of "xenctrl.h" used in RHEL5
(3.0.3 vintage), as well as the current version in Fedora (3.4.0-2.fc12) still use
unsigned int offsets, and I just checked with one of our xen masters, and the Xensource
git tree also still has unsigned int values in the header data structure: 

typedef struct xc_core_header {
    unsigned int xch_magic;
    unsigned int xch_nr_vcpus;
    unsigned int xch_nr_pages;
    unsigned int xch_ctxt_offset;
    unsigned int xch_index_offset;
    unsigned int xch_pages_offset;
} xc_core_header_t;

#define XC_CORE_MAGIC     0xF00FEBED
#define XC_CORE_MAGIC_HVM 0xF00FEBEE

Are your xen userspace tools an Oracle hybrid?

Dave