libxl: crash fails to load vmcore when the guest memory greater than 4G

libxl: crash fails to load vmcore when the guest memory greater than 4G

[Zhangwei (FF)]

[-- Attachment #1.1: Type: text/plain, Size: 2511 bytes --]

Description of problem:

A crash dump of a redhat5.5(32 bit) pae xen guest when the guest memory greater than 4G is not traceable, since crash can't figure out the phys_addr. But it’s ok when the guest memory less than 4G.
And so is it in the case of a suse11sp1(32 bit) pae xen guest.

Xen version: 4.1.2
dom0 version: suse11sp2(64bit)
How reproducible: Always

Steps to Reproduce:
1. Start redhat5.5（32bit） pae guest with memory greater than 4G
2. Take a crash dump of guest: xl dump-core <domid> <path-to-corefile-to-save>
3. crash vmlinux  <path-to-corefile-to-save>
    -- where vmlinux  is the unstripped vmlinux image that was used
       to generate the bootable vmlinuz of the redhat5.5(32bit) pae guest.


Actual results:
[root@localhost sdb]# crash vmlinux redhat_5.5_32_hvm_8G.core

crash 4.1.2-4.el5
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...

crash: read error: kernel virtual address: c0787540  type: "possible"
WARNING: cannot read cpu_possible_map
crash: read error: kernel virtual address: c06fffe0  type: "online"
WARNING: cannot read cpu_online_map
crash: read error: kernel virtual address: c068a340  type: "system_utsname"
crash: vmlinux and redhat_5.5_32_hvm_8G.core do not match!

Usage:
  crash [-h [opt]][-v][-s][-i file][-d num] [-S] [mapfile] [namelist] [dumpfile]

Enter "crash -h" for details.


Does anyone has any idea on this? Look forward to your reply.

Thank you.


[-- Attachment #1.2: Type: text/html, Size: 18402 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: libxl: crash fails to load vmcore when the guest memory greater than 4G

[Daniel Kiper]

On Thu, Jun 05, 2014 at 08:11:28AM +0000, Zhangwei (FF) wrote:
> Description of problem:
>
> A crash dump of a redhat5.5(32 bit) pae xen guest when the guest memory greater than 4G is not traceable, since crash can't figure out the phys_addr. But it??s ok when the guest memory less than 4G.
> And so is it in the case of a suse11sp1(32 bit) pae xen guest.
>
> Xen version: 4.1.2
> dom0 version: suse11sp2(64bit)
> How reproducible: Always
>
> Steps to Reproduce:
> 1. Start redhat5.5??32bit?? pae guest with memory greater than 4G
> 2. Take a crash dump of guest: xl dump-core <domid> <path-to-corefile-to-save>
> 3. crash vmlinux  <path-to-corefile-to-save>
>     -- where vmlinux  is the unstripped vmlinux image that was used
>        to generate the bootable vmlinuz of the redhat5.5(32bit) pae guest.
>
>
> Actual results:
> [root@localhost sdb]# crash vmlinux redhat_5.5_32_hvm_8G.core
>
> crash 4.1.2-4.el5

Oh... Please do not use such ancient version of crash. Download latest
version from http://people.redhat.com/anderson/ build it and voila...
If it does not work drop me a line.

Daniel

Re: libxl: crash fails to load vmcore when the guest memory greater than 4G

[Zhangwei (FF)]

Hi, Daniel
Thanks for replying.
The latest crash tool has the same problem. Following are the results.

When the guest memory greater than 4G(such as 8G), crash load vmcore failed.

[root@localhost sdb]# crash vmlinux redhat_5.5_32_hvm_8G.core crash 7.0.6 Copyright (C) 2002-2014  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation Copyright (C) 1999-2006  Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
crash: read error: kernel virtual address: c0787540  type: "possible"
WARNING: cannot read cpu_possible_map
crash: read error: kernel virtual address: c06fffe0  type: "online"
WARNING: cannot read cpu_online_map
crash: read error: kernel virtual address: c068a340  type: "system_utsname"
crash: vmlinux and redhat_5.5_32_hvm_8G.core do not match!
Usage:
  crash [OPTION]... NAMELIST MEMORY-IMAGE  (dumpfile form)
  crash [OPTION]... [NAMELIST]             (live system form)
Enter "crash -h" for details.

When the guest memory less than 4G(such as 3G), it's ok.

[root@localhost sdb]# crash vmlinux redhat_5.5_32_hvm_3G.core

crash 7.0.6
Copyright (C) 2002-2014  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation Copyright (C) 1999-2006  Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...

      KERNEL: vmlinux
    DUMPFILE: redhat_5.5_32_hvm_3G.core
        CPUS: 8
        DATE: Tue Jun  3 07:42:19 2014
      UPTIME: 00:25:11
LOAD AVERAGE: 0.00, 0.00, 0.00
       TASKS: 203
    NODENAME: localhost.localdomain
     RELEASE: 2.6.18-194.el5PAE
     VERSION: #1 SMP Tue Mar 16 22:00:21 EDT 2010
     MACHINE: i686  (2400 Mhz)
      MEMORY: 3.2 GB
       PANIC: ""
         PID: 0
     COMMAND: "swapper"
        TASK: c06893c0  (1 of 8)  [THREAD_INFO: c0701000]
         CPU: 0
       STATE: TASK_RUNNING (ACTIVE)
     WARNING: panic task not found

crash>


---------------------------------------------------------------------
Sender: Daniel Kiper [mailto:dkiper@net-space.pl] 
Send Time: 2014年6月5日 20:31
To: Zhangwei (FF)
CC: vincent.hanquez@eu.citrix.com; stefano.stabellini@eu.citrix.com; xen-devel@lists.xen.org; Chenguoping; Xuzhichuang
Topic: Re: [Xen-devel] libxl: crash fails to load vmcore when the guest memory greater than 4G

On Thu, Jun 05, 2014 at 08:11:28AM +0000, Zhangwei (FF) wrote:
> Description of problem:
>
> A crash dump of a redhat5.5(32 bit) pae xen guest when the guest memory greater than 4G is not traceable, since crash can't figure out the phys_addr. But it??s ok when the guest memory less than 4G.
> And so is it in the case of a suse11sp1(32 bit) pae xen guest.
>
> Xen version: 4.1.2
> dom0 version: suse11sp2(64bit)
> How reproducible: Always
>
> Steps to Reproduce:
> 1. Start redhat5.5??32bit?? pae guest with memory greater than 4G 2. 
> Take a crash dump of guest: xl dump-core <domid> 
> <path-to-corefile-to-save> 3. crash vmlinux  <path-to-corefile-to-save>
>     -- where vmlinux  is the unstripped vmlinux image that was used
>        to generate the bootable vmlinuz of the redhat5.5(32bit) pae guest.
>
>
> Actual results:
> [root@localhost sdb]# crash vmlinux redhat_5.5_32_hvm_8G.core
>
> crash 4.1.2-4.el5

Oh... Please do not use such ancient version of crash. Download latest version from http://people.redhat.com/anderson/ build it and voila...
If it does not work drop me a line.

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

Re: libxl: crash fails to load vmcore when the guest memory greater than 4G

[Daniel Kiper]

On Fri, Jun 06, 2014 at 02:00:40AM +0000, Zhangwei (FF) wrote:
> Hi, Daniel
> Thanks for replying.
> The latest crash tool has the same problem. Following are the results.
>
> When the guest memory greater than 4G(such as 8G), crash load vmcore failed.
>
> [root@localhost sdb]# crash vmlinux redhat_5.5_32_hvm_8G.core crash 7.0.6 Copyright (C) 2002-2014  Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation Copyright (C) 1999-2006  Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
> Copyright (C) 2005, 2011  NEC Corporation Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.  Enter "help copying" to see the conditions.
> This program has absolutely no warranty.  Enter "help warranty" for details.
> GNU gdb (GDB) 7.6
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu"...
> crash: read error: kernel virtual address: c0787540  type: "possible"
> WARNING: cannot read cpu_possible_map
> crash: read error: kernel virtual address: c06fffe0  type: "online"
> WARNING: cannot read cpu_online_map
> crash: read error: kernel virtual address: c068a340  type: "system_utsname"
> crash: vmlinux and redhat_5.5_32_hvm_8G.core do not match!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Are you sure that you use correct vmlinux file for this vmcore file?
If yes, could you put both vmcore files (good and bad one) and
vmlinux file somwhere for download? I will try to look at this
issue in week or two.

Daniel

Re: libxl: crash fails to load vmcore when the guest memory greater than 4G

[Zhangwei (FF)]

I'm not very sure, but if my vmlinux file is not correct, crash should load vmcore failed, whether the guest memory greater than 4G or not.

My vmlinux file was downloaded from: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/i386/Debuginfo/kernel-PAE-debuginfo-2.6.18-194.el5.i686.rpm

and I have send the vmlinux and vmcore files (good and bad one) download link to your email, you can use gunzip command to unzip these files.

In addition, my redhat5.5(32bit) guest os information:
[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.18-194.el5PAE #1 SMP Tue Mar 16 22:00:21 EDT 2010 i686 i686 i386 GNU/Linux [root@localhost ~]#


---------------------------------------------------------------------
Sender: Daniel Kiper [mailto:dkiper@net-space.pl] 
Send Time: 2014年6月7日 5:22
To: Zhangwei (FF)
CC: Daniel Kiper; vincent.hanquez@eu.citrix.com; stefano.stabellini@eu.citrix.com; xen-devel@lists.xen.org; Chenguoping; Xuzhichuang
Topic: Re: [Xen-devel] libxl: crash fails to load vmcore when the guest memory greater than 4G

On Fri, Jun 06, 2014 at 02:00:40AM +0000, Zhangwei (FF) wrote:
> Hi, Daniel
> Thanks for replying.
> The latest crash tool has the same problem. Following are the results.
>
> When the guest memory greater than 4G(such as 8G), crash load vmcore failed.
>
> [root@localhost sdb]# crash vmlinux redhat_5.5_32_hvm_8G.core crash 7.0.6 Copyright (C) 2002-2014  Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation Copyright (C) 1999-2006  Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
> Copyright (C) 2005, 2011  NEC Corporation Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.  Enter "help copying" to see the conditions.
> This program has absolutely no warranty.  Enter "help warranty" for details.
> GNU gdb (GDB) 7.6
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu"...
> crash: read error: kernel virtual address: c0787540  type: "possible"
> WARNING: cannot read cpu_possible_map
> crash: read error: kernel virtual address: c06fffe0  type: "online"
> WARNING: cannot read cpu_online_map
> crash: read error: kernel virtual address: c068a340  type: "system_utsname"
> crash: vmlinux and redhat_5.5_32_hvm_8G.core do not match!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Are you sure that you use correct vmlinux file for this vmcore file?
If yes, could you put both vmcore files (good and bad one) and vmlinux file somwhere for download? I will try to look at this issue in week or two.

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

Re: libxl: crash fails to load vmcore when the guest memory greater than 4G

[Don Slutz]

[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]

I was able to reproduce this. The issue that I found is that the file offset was
being truncated to a long (32bits...). The attached patch fixes my test case.

-Don Slutz

On 06/09/14 21:50, Zhangwei (FF) wrote:
> I'm not very sure, but if my vmlinux file is not correct, crash should load vmcore failed, whether the guest memory greater than 4G or not.
>
> My vmlinux file was downloaded from: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/i386/Debuginfo/kernel-PAE-debuginfo-2.6.18-194.el5.i686.rpm
>
> and I have send the vmlinux and vmcore files (good and bad one) download link to your email, you can use gunzip command to unzip these files.
>
> In addition, my redhat5.5(32bit) guest os information:
> [root@localhost ~]# uname -a
> Linux localhost.localdomain 2.6.18-194.el5PAE #1 SMP Tue Mar 16 22:00:21 EDT 2010 i686 i686 i386 GNU/Linux [root@localhost ~]#
>
>
> ---------------------------------------------------------------------
> Sender: Daniel Kiper [mailto:dkiper@net-space.pl] 
> Send Time: 2014年6月7日 5:22
> To: Zhangwei (FF)
> CC: Daniel Kiper; vincent.hanquez@eu.citrix.com; stefano.stabellini@eu.citrix.com; xen-devel@lists.xen.org; Chenguoping; Xuzhichuang
> Topic: Re: [Xen-devel] libxl: crash fails to load vmcore when the guest memory greater than 4G
>
> On Fri, Jun 06, 2014 at 02:00:40AM +0000, Zhangwei (FF) wrote:
>> Hi, Daniel
>> Thanks for replying.
>> The latest crash tool has the same problem. Following are the results.
>>
>> When the guest memory greater than 4G(such as 8G), crash load vmcore failed.
>>
>> [root@localhost sdb]# crash vmlinux redhat_5.5_32_hvm_8G.core crash 7.0.6 Copyright (C) 2002-2014  Red Hat, Inc.
>> Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation Copyright (C) 1999-2006  Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
>> Copyright (C) 2005, 2011  NEC Corporation Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
>> Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
>> This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.  Enter "help copying" to see the conditions.
>> This program has absolutely no warranty.  Enter "help warranty" for details.
>> GNU gdb (GDB) 7.6
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "i686-pc-linux-gnu"...
>> crash: read error: kernel virtual address: c0787540  type: "possible"
>> WARNING: cannot read cpu_possible_map
>> crash: read error: kernel virtual address: c06fffe0  type: "online"
>> WARNING: cannot read cpu_online_map
>> crash: read error: kernel virtual address: c068a340  type: "system_utsname"
>> crash: vmlinux and redhat_5.5_32_hvm_8G.core do not match!
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Are you sure that you use correct vmlinux file for this vmcore file?
> If yes, could you put both vmcore files (good and bad one) and vmlinux file somwhere for download? I will try to look at this issue in week or two.
>
> Daniel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #2: 0001-xendump-Use-off_t-not-long-for-32bit-code.patch --]
[-- Type: text/x-patch, Size: 13416 bytes --]

>From da2cef373c2d9faeb27adbf0d6c550199f7187e3 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
Date: Tue, 10 Jun 2014 17:24:48 +0000
Subject: [PATCH] xendump: Use off_t not long for 32bit code

This enables crash to handle xen dumps that are larger then 4G
in size in 32bit mode.

Signed-off-by: Don Slutz <dslutz@verizon.com>
---
 x86.c     | 10 ++++-----
 x86_64.c  | 10 ++++-----
 xendump.c | 74 +++++++++++++++++++++++++++++++++------------------------------
 xendump.h |  6 +++---
 4 files changed, 52 insertions(+), 48 deletions(-)

diff --git a/x86.c b/x86.c
index 833a11b..608bb88 100644
--- a/x86.c
+++ b/x86.c
@@ -4897,7 +4897,7 @@ x86_xendump_p2m_create(struct xendump_data *xd)
 		    "MEMBER_OFFSET(vcpu_guest_context, ctrlreg): %ld\n",
 			ctrlreg_offset);
 
-	offset = (off_t)xd->xc_core.header.xch_ctxt_offset + 
+	offset = xd->xc_core.header.xch_ctxt_offset +
 		(off_t)ctrlreg_offset;
 
 	if (lseek(xd->xfd, offset, SEEK_SET) == -1)
@@ -4997,7 +4997,7 @@ x86_pvops_xendump_p2m_create(struct xendump_data *xd)
 		    "MEMBER_OFFSET(vcpu_guest_context, ctrlreg): %ld\n",
 			ctrlreg_offset);
 
-	offset = (off_t)xd->xc_core.header.xch_ctxt_offset + 
+	offset = xd->xc_core.header.xch_ctxt_offset +
 		(off_t)ctrlreg_offset;
 
 	if (lseek(xd->xfd, offset, SEEK_SET) == -1)
@@ -5369,7 +5369,7 @@ x86_xendump_panic_task(struct xendump_data *xd)
 	    INVALID_MEMBER(cpu_user_regs_esp))
 		return NO_TASK;
 
-        offset = (off_t)xd->xc_core.header.xch_ctxt_offset +
+        offset = xd->xc_core.header.xch_ctxt_offset +
                 (off_t)OFFSET(vcpu_guest_context_user_regs) +
 		(off_t)OFFSET(cpu_user_regs_esp);
 
@@ -5419,7 +5419,7 @@ x86_get_xendump_regs(struct xendump_data *xd, struct bt_info *bt, ulong *eip, ul
             INVALID_MEMBER(cpu_user_regs_esp))
                 goto generic;
 
-        offset = (off_t)xd->xc_core.header.xch_ctxt_offset +
+        offset = xd->xc_core.header.xch_ctxt_offset +
                 (off_t)OFFSET(vcpu_guest_context_user_regs) +
                 (off_t)OFFSET(cpu_user_regs_esp);
         if (lseek(xd->xfd, offset, SEEK_SET) == -1)
@@ -5427,7 +5427,7 @@ x86_get_xendump_regs(struct xendump_data *xd, struct bt_info *bt, ulong *eip, ul
         if (read(xd->xfd, &xesp, sizeof(ulong)) != sizeof(ulong))
                 goto generic;
 
-        offset = (off_t)xd->xc_core.header.xch_ctxt_offset +
+        offset = xd->xc_core.header.xch_ctxt_offset +
                 (off_t)OFFSET(vcpu_guest_context_user_regs) +
                 (off_t)OFFSET(cpu_user_regs_eip);
         if (lseek(xd->xfd, offset, SEEK_SET) == -1)
diff --git a/x86_64.c b/x86_64.c
index f4a3e8b..a2e4636 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -6184,7 +6184,7 @@ x86_64_xendump_p2m_create(struct xendump_data *xd)
 		    "MEMBER_OFFSET(vcpu_guest_context, ctrlreg): %ld\n",
 			ctrlreg_offset);
 
-	offset = (off_t)xd->xc_core.header.xch_ctxt_offset + 
+	offset = xd->xc_core.header.xch_ctxt_offset +
 		(off_t)ctrlreg_offset;
 
 	if (lseek(xd->xfd, offset, SEEK_SET) == -1)
@@ -6270,7 +6270,7 @@ x86_64_pvops_xendump_p2m_create(struct xendump_data *xd)
 		    "MEMBER_OFFSET(vcpu_guest_context, ctrlreg): %ld\n",
 			ctrlreg_offset);
 
-	offset = (off_t)xd->xc_core.header.xch_ctxt_offset + 
+	offset = xd->xc_core.header.xch_ctxt_offset +
 		(off_t)ctrlreg_offset;
 
 	if (lseek(xd->xfd, offset, SEEK_SET) == -1)
@@ -6601,7 +6601,7 @@ x86_64_xendump_panic_task(struct xendump_data *xd)
 	    INVALID_MEMBER(cpu_user_regs_esp))
 		return NO_TASK;
 
-        offset = (off_t)xd->xc_core.header.xch_ctxt_offset +
+        offset = xd->xc_core.header.xch_ctxt_offset +
                 (off_t)OFFSET(vcpu_guest_context_user_regs) +
 		(off_t)OFFSET(cpu_user_regs_rsp);
 
@@ -6653,7 +6653,7 @@ x86_64_get_xendump_regs(struct xendump_data *xd, struct bt_info *bt, ulong *rip,
             INVALID_MEMBER(cpu_user_regs_rsp))
                 goto generic;
 
-        offset = (off_t)xd->xc_core.header.xch_ctxt_offset +
+        offset = xd->xc_core.header.xch_ctxt_offset +
                 (off_t)OFFSET(vcpu_guest_context_user_regs) +
                 (off_t)OFFSET(cpu_user_regs_rsp);
         if (lseek(xd->xfd, offset, SEEK_SET) == -1)
@@ -6661,7 +6661,7 @@ x86_64_get_xendump_regs(struct xendump_data *xd, struct bt_info *bt, ulong *rip,
         if (read(xd->xfd, &xrsp, sizeof(ulong)) != sizeof(ulong))
                 goto generic;
 
-        offset = (off_t)xd->xc_core.header.xch_ctxt_offset +
+        offset = xd->xc_core.header.xch_ctxt_offset +
                 (off_t)OFFSET(vcpu_guest_context_user_regs) +
                 (off_t)OFFSET(cpu_user_regs_rip);
         if (lseek(xd->xfd, offset, SEEK_SET) == -1)
diff --git a/xendump.c b/xendump.c
index 6d6b51e..9d78916 100644
--- a/xendump.c
+++ b/xendump.c
@@ -126,9 +126,9 @@ xc_core_verify(char *file, char *buf)
 	xd->xc_core.header.xch_magic = xcp->xch_magic;
 	xd->xc_core.header.xch_nr_vcpus = xcp->xch_nr_vcpus;
 	xd->xc_core.header.xch_nr_pages = xcp->xch_nr_pages;
-	xd->xc_core.header.xch_ctxt_offset = (ulong)xcp->xch_ctxt_offset;
-	xd->xc_core.header.xch_index_offset = (ulong)xcp->xch_index_offset;
-	xd->xc_core.header.xch_pages_offset = (ulong)xcp->xch_pages_offset;
+	xd->xc_core.header.xch_ctxt_offset = (off_t)xcp->xch_ctxt_offset;
+	xd->xc_core.header.xch_index_offset = (off_t)xcp->xch_index_offset;
+	xd->xc_core.header.xch_pages_offset = (off_t)xcp->xch_pages_offset;
 
         xd->flags |= (XENDUMP_LOCAL | XC_CORE_ORIG | XC_CORE_P2M_CREATE);
 
@@ -187,7 +187,7 @@ xc_core_read(void *bufptr, int cnt, ulong addr, physaddr_t paddr)
 	    PFN_NOT_FOUND)
 		return READ_ERROR;
 
-	offset = (off_t)xd->xc_core.header.xch_pages_offset +
+	offset = xd->xc_core.header.xch_pages_offset +
 		((off_t)(page_index) * (off_t)xd->page_size);
 
 	if (lseek(xd->xfd, offset, SEEK_SET) == -1) 
@@ -852,7 +852,7 @@ read_xendump_hyper(int fd, void *bufptr, int cnt, ulong addr, physaddr_t paddr)
         if ((page_index = xc_core_mfn_to_page_index(pfn)) == PFN_NOT_FOUND)
                 return READ_ERROR;
 
-        offset = (off_t)xd->xc_core.header.xch_pages_offset +
+        offset = xd->xc_core.header.xch_pages_offset +
                 ((off_t)(page_index) * (off_t)xd->page_size);
 
         if (lseek(xd->xfd, offset, SEEK_SET) == -1)
@@ -1040,15 +1040,15 @@ xendump_memory_dump(FILE *fp)
 	fprintf(fp, "             xch_nr_pages: %d (0x%x)\n",
 		xd->xc_core.header.xch_nr_pages,
 		xd->xc_core.header.xch_nr_pages);
-	fprintf(fp, "          xch_ctxt_offset: %ld (0x%lx)\n", 
-		xd->xc_core.header.xch_ctxt_offset,
-		xd->xc_core.header.xch_ctxt_offset);
-	fprintf(fp, "         xch_index_offset: %ld (0x%lx)\n",
-		xd->xc_core.header.xch_index_offset,
-		xd->xc_core.header.xch_index_offset);
-	fprintf(fp, "         xch_pages_offset: %ld (0x%lx)\n",
-		xd->xc_core.header.xch_pages_offset,
-		xd->xc_core.header.xch_pages_offset);
+	fprintf(fp, "          xch_ctxt_offset: %llu (0x%llx)\n",
+		(ulonglong)xd->xc_core.header.xch_ctxt_offset,
+		(ulonglong)xd->xc_core.header.xch_ctxt_offset);
+	fprintf(fp, "         xch_index_offset: %llu (0x%llx)\n",
+		(ulonglong)xd->xc_core.header.xch_index_offset,
+		(ulonglong)xd->xc_core.header.xch_index_offset);
+	fprintf(fp, "         xch_pages_offset: %llu (0x%llx)\n",
+		(ulonglong)xd->xc_core.header.xch_pages_offset,
+		(ulonglong)xd->xc_core.header.xch_pages_offset);
 
 	fprintf(fp, "                elf_class: %s\n", xd->xc_core.elf_class == ELFCLASS64 ? "ELFCLASS64" :
 		xd->xc_core.elf_class == ELFCLASS32 ? "ELFCLASS32" : "n/a");
@@ -1285,7 +1285,7 @@ xc_core_mfn_to_page(ulong mfn, char *pgbuf)
 	if (xd->flags & XC_CORE_ELF)
 		return xc_core_elf_mfn_to_page(mfn, pgbuf);
 
-        if (lseek(xd->xfd, (off_t)xd->xc_core.header.xch_index_offset,
+        if (lseek(xd->xfd, xd->xc_core.header.xch_index_offset,
             SEEK_SET) == -1) {
                 error(INFO, "cannot lseek to page index\n");
 		return NULL;
@@ -1325,7 +1325,7 @@ xc_core_mfn_to_page(ulong mfn, char *pgbuf)
 		return NULL;
 	}
 
-        if (lseek(xd->xfd, (off_t)xd->xc_core.header.xch_pages_offset,
+        if (lseek(xd->xfd, xd->xc_core.header.xch_pages_offset,
             SEEK_SET) == -1) {
                 error(INFO, "cannot lseek to xch_pages_offset\n");
 		return NULL;
@@ -1400,7 +1400,7 @@ xc_core_elf_mfn_to_page(ulong mfn, char *pgbuf)
 		return NULL;
 	}
 
-        if (lseek(xd->xfd, (off_t)xd->xc_core.header.xch_pages_offset,
+        if (lseek(xd->xfd, xd->xc_core.header.xch_pages_offset,
             SEEK_SET) == -1)
                 error(FATAL, "cannot lseek to xch_pages_offset\n");
 
@@ -1434,7 +1434,7 @@ xc_core_mfn_to_page_index(ulong mfn)
 	if (xd->flags & XC_CORE_ELF)
 		return xc_core_elf_mfn_to_page_index(mfn);
 
-        if (lseek(xd->xfd, (off_t)xd->xc_core.header.xch_index_offset,
+        if (lseek(xd->xfd, xd->xc_core.header.xch_index_offset,
             SEEK_SET) == -1) {
                 error(INFO, "cannot lseek to page index\n");
                 return MFN_NOT_FOUND;
@@ -1527,7 +1527,7 @@ xc_core_mfns(ulong arg, FILE *ofp)
         ulonglong tmp64[MAX_BATCH_SIZE];
 	size_t size;
 
-        if (lseek(xd->xfd, (off_t)xd->xc_core.header.xch_index_offset,
+        if (lseek(xd->xfd, xd->xc_core.header.xch_index_offset,
             SEEK_SET) == -1) {
                 error(INFO, "cannot lseek to page index\n");
 		return FALSE;
@@ -1677,7 +1677,7 @@ xc_core_pfn_to_page_index(ulong pfn)
 
 	p2m_idx = xd->xc_core.p2m_frame_index_list[idx];
 
-	if (lseek(xd->xfd, (off_t)xd->xc_core.header.xch_pages_offset,
+	if (lseek(xd->xfd, xd->xc_core.header.xch_pages_offset,
             SEEK_SET) == -1) {
                 error(INFO, "cannot lseek to xch_pages_offset\n");
                 return PFN_NOT_FOUND;
@@ -1801,7 +1801,7 @@ xc_core_pfn_valid(ulong pfn)
 	if (pfn >= (ulong)xd->xc_core.header.xch_nr_pages)
 		return FALSE;
 
-        offset = (off_t)xd->xc_core.header.xch_index_offset;
+        offset = xd->xc_core.header.xch_index_offset;
 
 	if (xd->flags & XC_CORE_64BIT_HOST)
 		offset += (off_t)(pfn * sizeof(ulonglong));
@@ -2542,25 +2542,27 @@ xc_core_dump_Elf32_Shdr(Elf32_Off offset, int store)
 		return;
 
 	if (STREQ(name, ".xen_prstatus"))
-		xd->xc_core.header.xch_ctxt_offset = 
-			(unsigned long)shdr.sh_offset;
+		xd->xc_core.header.xch_ctxt_offset =
+			(off_t)shdr.sh_offset;
 
 	if (STREQ(name, ".xen_shared_info"))
 		xd->xc_core.shared_info_offset = (off_t)shdr.sh_offset;
 
 	if (STREQ(name, ".xen_pfn")) {
-		xd->xc_core.header.xch_index_offset = shdr.sh_offset;
+		xd->xc_core.header.xch_index_offset =
+			(off_t)shdr.sh_offset;
 		xd->flags |= (XC_CORE_NO_P2M|XC_CORE_PFN_CREATE);
 	}
 
 	if (STREQ(name, ".xen_p2m")) {
-		xd->xc_core.header.xch_index_offset = shdr.sh_offset;
+		xd->xc_core.header.xch_index_offset =
+			(off_t)shdr.sh_offset;
 		xd->flags |= XC_CORE_P2M_CREATE;
 	}
 
 	if (STREQ(name, ".xen_pages"))
-		xd->xc_core.header.xch_pages_offset = 
-			(unsigned long)shdr.sh_offset;
+		xd->xc_core.header.xch_pages_offset =
+			(off_t)shdr.sh_offset;
 
 	if (STREQ(name, ".xen_ia64_mapped_regs"))
 		xd->xc_core.ia64_mapped_regs_offset = 
@@ -2642,25 +2644,27 @@ xc_core_dump_Elf64_Shdr(Elf64_Off offset, int store)
 		return;
 
 	if (STREQ(name, ".xen_prstatus"))
-		xd->xc_core.header.xch_ctxt_offset = 
-			(unsigned long)shdr.sh_offset;
+		xd->xc_core.header.xch_ctxt_offset =
+			(off_t)shdr.sh_offset;
 
 	if (STREQ(name, ".xen_shared_info"))
 		xd->xc_core.shared_info_offset = (off_t)shdr.sh_offset;
 
 	if (STREQ(name, ".xen_pfn")) {
-		xd->xc_core.header.xch_index_offset = shdr.sh_offset;
+		xd->xc_core.header.xch_index_offset =
+			(off_t)shdr.sh_offset;
 		xd->flags |= (XC_CORE_NO_P2M|XC_CORE_PFN_CREATE);
 	}
 
 	if (STREQ(name, ".xen_p2m")) {
-		xd->xc_core.header.xch_index_offset = shdr.sh_offset;
+		xd->xc_core.header.xch_index_offset =
+			(off_t)shdr.sh_offset;
 		xd->flags |= XC_CORE_P2M_CREATE;
 	}
 
 	if (STREQ(name, ".xen_pages"))
-		xd->xc_core.header.xch_pages_offset = 
-			(unsigned long)shdr.sh_offset;
+		xd->xc_core.header.xch_pages_offset =
+			(off_t)shdr.sh_offset;
 
 	if (STREQ(name, ".xen_ia64_mapped_regs"))
 		xd->xc_core.ia64_mapped_regs_offset = 
@@ -2814,7 +2818,7 @@ xc_core_elf_pfn_init(void)
 		chunk = xd->xc_core.header.xch_nr_pages/INDEX_PFN_COUNT;
 
 		for (i = c = 0; i < INDEX_PFN_COUNT; i++, c += chunk) {
-			offset = (off_t)xd->xc_core.header.xch_index_offset +
+			offset = xd->xc_core.header.xch_index_offset +
 				(off_t)(c * sizeof(uint64_t));
 
 	        	if (lseek(xd->xfd, offset, SEEK_SET) == -1)
@@ -2834,7 +2838,7 @@ xc_core_elf_pfn_init(void)
 		chunk = xd->xc_core.header.xch_nr_pages/INDEX_PFN_COUNT;
 	
 		for (i = c = 0; i < INDEX_PFN_COUNT; i++, c += chunk) {
-			offset = (off_t)xd->xc_core.header.xch_index_offset +
+			offset = xd->xc_core.header.xch_index_offset +
 				(off_t)(c * sizeof(struct xen_dumpcore_p2m));
 
 	        	if (lseek(xd->xfd, offset, SEEK_SET) == -1)
diff --git a/xendump.h b/xendump.h
index 9ece4da..17aae37 100644
--- a/xendump.h
+++ b/xendump.h
@@ -42,9 +42,9 @@ struct xen_core_header {
     unsigned int xch_magic;
     unsigned int xch_nr_vcpus;
     unsigned int xch_nr_pages;
-    unsigned long xch_ctxt_offset;
-    unsigned long xch_index_offset;
-    unsigned long xch_pages_offset;
+    off_t xch_ctxt_offset;
+    off_t xch_index_offset;
+    off_t xch_pages_offset;
 };
 
 struct pfn_offset_cache {
-- 
1.7.11.7


[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: libxl: crash fails to load vmcore when the guest memory greater than 4G

[Daniel Kiper]

On Tue, Jun 10, 2014 at 02:14:40PM -0400, Don Slutz wrote:
> I was able to reproduce this. The issue that I found is that the file offset was
> being truncated to a long (32bits...). The attached patch fixes my test case.

Zhangwei, could you test Don's patch?

Daniel

Re: libxl: crash fails to load vmcore when the guest memory greater than 4G

[Zhangwei (FF)]

Yes, I have used the patch, and it work.

Thanks Don Slutz and Daniel for timely help.

-zhangwei

-------------------------------------------------
Sender: Daniel Kiper [mailto:dkiper@net-space.pl] 
Send Time: 2014年6月12日 3:19
To: Don Slutz
CC: Zhangwei (FF); Daniel Kiper; Chenguoping; xen-devel@lists.xen.org; vincent.hanquez@eu.citrix.com; Xuzhichuang; stefano.stabellini@eu.citrix.com; Discussion list for crash utility usage, maintenance and development
Topic: Re: [Xen-devel] libxl: crash fails to load vmcore when the guest memory greater than 4G

On Tue, Jun 10, 2014 at 02:14:40PM -0400, Don Slutz wrote:
> I was able to reproduce this. The issue that I found is that the file 
> offset was being truncated to a long (32bits...). The attached patch fixes my test case.

Zhangwei, could you test Don's patch?

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