Re: [PATCH] add arm support for libgcore

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

 




----- Original Message -----
> Hi HATAYAMA,
> 
> On Tue, Feb 14, 2012 at 9:37 AM, HATAYAMA Daisuke
> <d.hatayama@xxxxxxxxxxxxxx> wrote:
> > From: Lei Wen <adrian.wenl@xxxxxxxxx>
> > Subject: Re:  [PATCH] add arm support for libgcore
> > Date: Mon, 13 Feb 2012 17:03:02 +0800
> >
> >> Hi Hatayama,
> >>
> >> On Mon, Feb 13, 2012 at 4:33 PM, HATAYAMA Daisuke
> >> <d.hatayama@xxxxxxxxxxxxxx> wrote:
> >>> Hello Lei,
> >>>
> >>> Thanks for making patch. I'll check your patch this week, but I have
> >>> two things to ask you.
> >>>
> >>> 1. I don't know arm architecture at all and I don't have arm
> >>> machine. What I can do is only testing common part and regression test
> >>> on x86 architecture. Please maintain arm part yourself.
> >>
> >> Sure, it is my pleasure. :)
> >>
> >>>
> >>> 2. Could you tell me specific kernel versions you have tested this
> >>> patch in? I myself have yet to do this, but now I think it necessary
> >>> to make such a list. I imagine just like makedumpfile's SUPPORTED
> >>> KERNELS described in its README. I'll put them in gcore's README and
> >>> then ask Dave to add them into description in distribution page.
> >>
> >> I am current testing with kernel 2.6.35.7 and 3.0.8, and they are both ok.
> >
> > I see.
> >
> >> But I see below warnings during extracting, while the extracted core
> >> dump image is OK for gdb, I don't know whether it there is still some missing in
> >> original implementation, or those pages just don't existed in memory?
> >>
> >> gcore: PT_LOAD[165]: af900000 - af90e000
> >> gcore: WARNING: page fault at af909000
> >> gcore: WARNING: page fault at af90d000
> >
> > These are verbose messages, which you can specify which to display via
> > -v option. Please see help message in detail. However, important is
> > "page fault" message below.
> >
> >> gcore: WARNING: page fault at af909000
> >> gcore: WARNING: page fault at af90d000
> >
> > Most of crash dump mechanism doesn't collect swap space, such as
> > kdump, diskdump, so in essence, crash gcore doesn't try to collect
> > such paged-out user-space memory.
> >
> > crash gcore instead fills the paged-out memory with zero; this
> > is easier implementation than reconstracting program headers.
> >
> > The reason why I've included the ``page fault'' in the default warning
> > message is to avoid the situation where users get confused they have
> > successfully got complete user-space coredump.
> >
> > GDB tends to work well because part of user stack necessary for
> > backtrace is not paged out most of time; of course, the backtrace
> > would fail if paged-out.
> >
> > Thanks.
> > HATAYAMA, Daisuke
> >
> 
> I see, thanks for detailed explanation.
> My another curious is whether we could refill those missing swapped page, if
> we provide whole swap partition data?
> 
> Thanks,
> Lei

Aren't most of those "page fault" references that you see
during a gcore operation typically referring to pages that 
exist in the target task's virtual memory map but have not
been referenced?

Dave




 

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility


[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux