----- "xiaowei hu" <xiaowei.hu@xxxxxxxxxx> 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@xxxxxxxxxx>
>
>
> 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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
