[PATCH 0/3] makedumpfile-1.0.6: Fix the ELF dumpfile

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Ken'ichi Ohmichi wrote:

>
>
> Hi.
>
> makedumpfile version 1.0.6 is released.
> This version fixes 2 problems.
>
> [1/3] Fix the physical address for i386PAE
> [2/3] Fix the ELF dumpfile
> [3/3] Update the version info
>
> Please test it, and your opinions/comments are welcome.
>

[ snip ]

>
>
> - [2/3] Fix the ELF dumpfile
>   The second problem is that gdb can not analyze the ELF dumpfile.
>   When I created the feature of the ELF dumpfile output, I did not
>   consider that PT_LOAD is not on page_size boundary. If PT_LOAD is
>   not on page_size boundary, gdb can not analyze it.
>
>   Even if you apply the attached patchset to makedumpfile, the crash
>   utility can not read the ELF dumpfile in some case. Because necessary
>   zero pages are excluded.
>
>   I created the feature of the ELF dumpfile output only for gdb, not for
>   the crash utility. The crash utility considers the excluded page of
>   the ELF dumpfile to be unaccessible area. If necessary zero pages are
>   excluded, the crash utility can not analyze it.
>   http://lists.osdl.org/pipermail/fastboot/2006-April/002819.html
>
>   If you use the crash utility, please do not select the ELF dumpfile
>   format.

Hi Ken'ichi,

Can you explain this issue a bit more?

Exactly what is a "necessary zero page" that causes the crash
session to fail?

The crash utility's read_diskdump() function, which is only used when
the dumpfile is in the compressed diskdump format, has this:

        if (!page_is_dumpable(pfn)) {
                memset(bufptr, 0, cnt);
                return cnt;
        }

which returns a page of zeroes if the page is not included in
the diskdump.

If the diskdump is *not* compressed, diskdump creates an ELF
vmcore that is indistinguishable from a netdump ELF vmcore -- which
does not create a zero-filled page as done above.

We had this discussion on another list, and none of the diskdump
developers could remember why they wanted crash to do it that way
with compressed diskdumps.  I vaguely remember that
it had something to do with a crucial page being left out of
the compressed dump, but I really can't say that for sure.  But
if a page of zeroes was returned, the zero-values found in the
"fake" page seemed to be enough for the crash utility code path
to continue on harmlessly.

Anyway, it sounds like you have run into the same issue.

So it would be very helpful to explain exactly what types of
page(s) are not being saved, and exactly where in the crash
utility the fatal error occurs.

Preferably we should make crash be able to handle it
if possible, rather than stating "please do not select the
ELF dumpfile format".

Thanks,
  Dave






[Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Linux Media]     [Linux Resources]

Powered by Linux