[Crash-utility] segv in crash-5.0.0

[Dave Anderson]

----- "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"
> crash> x/xg 0xffffc90006b000cf
> 0xffffc90006b000cf:     gdb: invalid kernel virtual address:
> ffffc90006b000cf  type: "gdb_readmem_callback"
> Cannot access memory at address 0xffffc90006b000cf
> gdb: gdb request failed: x/xg
> crash>
> 
> But with the struct access:
> 
> crash> struct bnx2 0xffffc90006b000cf
> struct bnx2 struct: invalid kernel virtual address: ffffc90006b000cf type: "gdb_readmem_callback"
> gdb called without error_hook: Cannot access memory at address 0xffffc90006b000cf
> *** glibc detected *** /home/bobm/Crash/crash-5.0.0/crash: double free
> or corruption (!prev): 0x0000000007144210 ***
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fd3c65781af in ?? () from /lib/libgcc_s.so.1
> (gdb)
> (gdb) bt
> #0  0x00007fd3c65781af in ?? () from /lib/libgcc_s.so.1
> #1  0x00007fd3c6578a7b in _Unwind_Backtrace () from /lib/libgcc_s.so.1
> #2  0x00007fd3cda735ae in backtrace () from /lib/libc.so.6
> #3  0x00007fd3cda013bc in __libc_message () from /lib/libc.so.6
> #4  0x00007fd3cda06948 in malloc_printerr () from /lib/libc.so.6
> #5  0x00007fd3cda08a56 in free () from /lib/libc.so.6
> #6  0x000000000058807a in parse_exp_in_context (stringptr=0x7fffb04cdc20,
>     block=<value optimized out>, comma=<value optimized out>,
>     void_context_p=32723, out_subexp=0x7fffb04cdba0) at parse.c:1101
> #7  0x0000001d06b000cf in ?? ()
> #8  0x0000000000000000 in ?? ()
> 
> 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...

Thanks,
  Dave