[Fwd: [Crash-utility] crash warnings]

[David Wilder]

.....

> Hi Dave,
>
> Like Badari's issue, which actually was a non-issue, it's
> difficult to debug from here.
>
> A couple things...
>
> When you use an additional System.map argument on the command
> line, you should see the message stating that several thousand
> symbol values are being changed from what is in the vmlinux file
> to what is in the System.map file:
>
>   please wait... (patching ##### gdb minimal_symbol values)
>
> This gets kicked off in the gdb_interface.c gdb_session_init() function
> here:
>
>        /*
>         *  Patch gdb's symbol values with the correct values from either
>         *  the System.map or non-debug vmlinux, whichever is in effect.
>         */
>         if ((pc->flags & SYSMAP) ||
>             (pc->namelist_debug && !pc->debuginfo_file)) {
>                 req->command = GNU_PATCH_SYMBOL_VALUES;
>                 req->flags = GNU_RETURN_ON_ERROR;
>                 gdb_interface(req);
>                 if (req->flags & GNU_COMMAND_FAILED)
>                         error(FATAL, "patching of gdb symbol values 
> failed\n");
>         }
>
> So, presuming that worked OK, what's strange is the read error
> you get on the vmcore:
>
>>crash: read error: kernel virtual address: c00000000fa26940 type: "first vmlist addr"
>>
>
> The first_vmalloc_address() function is simply reading
> reading the contents of the vmlist pointer, which points
> to the first vm_struct in the list, and which is returning
> c00000000fa26940.  But then it fails to read what's in the
> "addr" offset of the vm_struct at that address:
>
>         get_symbol_data("vmlist", sizeof(void *), &vmlist);
>
>         if (!readmem(vmlist+OFFSET(vm_struct_addr), KVADDR, &addr,
>             sizeof(void *), "first vmlist addr", RETURN_ON_ERROR))
>                 non_matching_kernel();
>
> Since the "addr" offset is 0, it just reads address
> c00000000fa26940, which is a just a kmalloc'd unity-mapped
> address.
>
> So the question is, why is that address not capable of being
> read from the vmcore?  If you do a "help -n" to dump the
> header contents of the vmcore, does physical address fa26940
> not fit into any of the PT_LOAD segments?
>
> (Again -- this all presumes the the "vmlist" symbol address is
> correct...)
>
> Dave
>  
>  
>
>------------------------------------------------------------------------
>
>--
>Crash-utility mailing list
>Crash-utility at redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>  
>
crash -d 2 gave me the header..
Elf64_Phdr:
                 p_type: 4 (PT_NOTE)
               p_offset: 288 (120)
                p_vaddr: 0
                p_paddr: 0
               p_filesz: 1048 (418)
                p_memsz: 1048 (418)
                p_flags: 0 ()
                p_align: 0
Elf64_Phdr:
                 p_type: 1 (PT_LOAD)
               p_offset: 1336 (538)
                p_vaddr: c000000000000000
                p_paddr: 0
               p_filesz: 32768 (8000)
                p_memsz: 32768 (8000)
                p_flags: 7 (PF_X|PF_W|PF_R)
                p_align: 0
Elf64_Phdr:
                 p_type: 1 (PT_LOAD)
               p_offset: 34104 (8538)
                p_vaddr: c000000000008000
                p_paddr: 8000
               p_filesz: 33521663 (1ff7fff)
                p_memsz: 33521663 (1ff7fff)
                p_flags: 7 (PF_X|PF_W|PF_R)
                p_align: 0
Elf64_Phdr:
                 p_type: 1 (PT_LOAD)
               p_offset: 33555767 (2000537)
                p_vaddr: c00000002fd0f001
                p_paddr: 2fd0f001
               p_filesz: 3492745215 (d02f0fff)
                p_memsz: 3492745215 (d02f0fff)
                p_flags: 7 (PF_X|PF_W|PF_R)
                p_align: 0

Looks like that address is in a hole between PT_LOAD segments 2 and 3. 

-- 
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA 
dwilder at us.ibm.com
(503)578-3789