segv in crash-5.0.0

I accidentally tried to dump a struct from a bogus pointer while using
crash-5.0.0 on x86-64.

In crash-4.1.1, the result was:
crash> struct bnx2 0xffffc90006b000cf
struct bnx2 struct: invalid kernel virtual address: ffffc90006b000cf
type: "gdb_readmem_callback"
Cannot access memory at address 0xffffc90006b000cf
crash> 

On crash-5.0.0, the result was:
crash-5.0> struct bnx2 0xffffc90006b000cf
struct bnx2 struct: invalid kernel virtual address: ffffc90006b000cf
type: "gdb_readmem_callback"
*** glibc detected *** crash-5.0: double free or corruption (!prev):
0x0000000006f94e60 ***
gdb called without error_hook: Cannot access memory at address
0xffffc90006b000cf
   <segmentation violation in gdb>

[[ Here the process hung, and I had to kill -9 it ]]

While running crash-5.0.0 under gdb, I tried some non-struct accesses of
the location first:
crash> rd 0xffffc90006b000cf 10
rd: invalid kernel virtual address: ffffc90006b000cf  type: "64-bit
KVADDR"
crash> x/xg 0xffffc90006b000cf
0xffffc90006b000cf:     gdb: invalid kernel virtual address:
ffffc90006b000cf  type: "gdb_readmem_callback"

Re: segv in crash-5.0.0

----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:

> I accidentally tried to dump a struct from a bogus pointer while using
> crash-5.0.0 on x86-64.
> 
> In crash-4.1.1, the result was:
> crash> struct bnx2 0xffffc90006b000cf
> struct bnx2 struct: invalid kernel virtual address: ffffc90006b000cf
> type: "gdb_readmem_callback"
> Cannot access memory at address 0xffffc90006b000cf
> crash> 
> 
> On crash-5.0.0, the result was:
> crash-5.0> struct bnx2 0xffffc90006b000cf
> struct bnx2 struct: invalid kernel virtual address: ffffc90006b000cf
> type: "gdb_readmem_callback"
> *** glibc detected *** crash-5.0: double free or corruption (!prev):
> 0x0000000006f94e60 ***
> gdb called without error_hook: Cannot access memory at address
> 0xffffc90006b000cf
>    <segmentation violation in gdb>
> 
> [[ Here the process hung, and I had to kill -9 it ]]
> 
> 
> While running crash-5.0.0 under gdb, I tried some non-struct accesses of
> the location first:
> crash> rd 0xffffc90006b000cf 10
> rd: invalid kernel virtual address: ffffc90006b000cf  type: "64-bit KVADDR"

Re: segv in crash-5.0.0

----- "Dave Anderson" <anderson <at> redhat.com> wrote:

> ----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:
> 
> > I accidentally tried to dump a struct from a bogus pointer while using
> > crash-5.0.0 on x86-64.

... [ snip ] ...

> > Enough to go on?  Already known?
> 
> Not already known...  
> 
> But I can reproduce it (at least with some bogus addresses) -- I'll take
> a look at it tomorrow...

Caused by a slight change in the crash/gdb-7.0 exception handling.
Simple fix attached...

Thanks,
  Dave

----- "Dave Anderson" <anderson <at> redhat.com> wrote:

> ----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:
> 

Re: segv in crash-5.0.0

On Tue, 2010-02-02 at 14:48 +0000, Dave Anderson wrote:
> ----- "Dave Anderson" <anderson <at> redhat.com> wrote:
> 
> > ----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:
> > 
> > > I accidentally tried to dump a struct from a bogus pointer while using
> > > crash-5.0.0 on x86-64.
> 
> ... [ snip ] ...
> 
> > > Enough to go on?  Already known?
> > 
> > Not already known...  
> > 
> > But I can reproduce it (at least with some bogus addresses) -- I'll take
> > a look at it tomorrow...
> 
> Caused by a slight change in the crash/gdb-7.0 exception handling.
> Simple fix attached...

The patch fixed the problem on my dump file.  It now prints:

crash-5.0.fix> struct bnx2 0xffffc90006b000cf
struct bnx2 struct: invalid kernel virtual address: ffffc90006b000cf
type: "gdb_readmem_callback"Cannot access memory at address
0xffffc90006b000cf

crash-5.0.fix>

Thanks,

Re: Crash Subscription - Something Wrong

Dave Anderson wrote:
> Piet Delaney wrote:
>> Hi Dave [I moved]:
>>
>> I subscribed to your crash mailing list last evening and didn't receive 
>> anything yet.
>> Looks like there was a posting today.
> 
> I remember approving your subscription request.  Looking at the current
> list of subscribers, I see these two:
> 
>    Piet.Delaney <at> tensilica.com
>    piet <at> bluelane.com
> 
>> How much work do you think it would take to add the xtensa architecture 
>> to crash?
>>  From our IA64 work together I recall it mostly being the backtrace code 
>> needing work.
> 
> That's certainly a big part of it, but that's only the "gravy" that needs
> to be done after all of the foundational work is done.  New architectures
> basically require:
> 
> 1. cloning the arch-specific parts of configure.c so that there
>     can be "#ifdef XTENSA" parts of the code.
> 2. creating a new "xtensa.c" file that satisfies all of the
>     requirements for the generic machdep-><architecture-data> and
>     machdep-><architecture-function> fields used throughout the
>     common code.  The crash sources do contain a template PLATFORM.c
>     file, which is a bit dated and will most likely not have everything

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

----- "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.

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

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

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

----- "Dave Anderson" <anderson <at> redhat.com> wrote:

> ----- "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

答复: Re: [patch]Crash can't process xen dump core files larger that 4GB.

----- "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.
> 

[PATCH] s390: Member names changed in struct _lowcore

Hi,

For s390 the "st_status_fixed_logout" member of "struct _lowcore" will be
changed to "psw_save_area" in 2.6.33. This patch will ensure that the correct
member will be used depending on the kernel version.

Best Regards

Michael
---
 defs.h  |    1 +
 s390.c  |   24 ++++++++++++++++++------
 s390x.c |   23 ++++++++++++++++++-----
 3 files changed, 37 insertions(+), 11 deletions(-)

--- a/defs.h
+++ b/defs.h
 <at>  <at>  -1494,6 +1494,7  <at>  <at>  struct offset_table {                   
 	long attribute_owner;
 	long module_sect_attr_attr;
 	long module_sections_attrs;
+	long s390_lowcore_psw_save_area;
 };

 struct size_table {         /* stash of commonly-used sizes */
--- a/s390.c
+++ b/s390.c
 <at>  <at>  -69,6 +69,19  <at>  <at>  static int s390_is_uvaddr(ulong, struct