Hi, Current the crash utility has the support for extracting core dump image from original kdump file: http://people.redhat.com/anderson/extensions/gcore_help_gcore.html But it only supports x86 and x86_64 now. I add one supporting patch to port it to ARM and another fix a minor bug in original implementation. Best regards, Lei

Hi Hatayama, On Mon, Feb 13, 2012 at 4:33 PM, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com&gt; 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.

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

gcore: WARNING: page fault at af909000 gcore: WARNING: page fault at af90d000

Hi HATAYAMA, On Tue, Feb 14, 2012 at 9:37 AM, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com&gt; wrote: > From: Lei Wen <adrian.wenl(a)gmail.com&gt; > Subject: Re: [Crash-utility] [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(a)jp.fujitsu.com&gt; 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

----- Original Message ----- ... > > > 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? For example, none of these pages are swapped out: crash> gcore 1951 gcore: WARNING: FPU may be inaccurate: 1951 gcore: WARNING: page fault at 386df98000 gcore: WARNING: page fault at 386df99000 gcore: WARNING: page fault at 386df9e000 gcore: WARNING: page fault at 386df9f000 gcore: WARNING: page fault at 7fff632f3000 gcore: WARNING: page fault at 7fff632f4000 gcore: WARNING: page fault at 7fff632f5000 gcore: WARNING: page fault at 7fff632f6000 gcore: WARNING: page fault at 7fff632f7000 gcore: WARNING: page fault at 7fff632f8000 gcore: WARNING: page fault at 7fff632f9000 gcore: WARNING: page fault at 7fff632fa000 gcore: WARNING: page fault at 7fff632fb000 gcore: WARNING: page fault at 7fff632fc000 gcore: WARNING: page fault at 7fff632fd000 gcore: WARNING: page fault at 7fff632fe000 gcore: WARNING: page fault at 7fff632ff000 gcore: WARNING: page fault at 7fff63300000 gcore: WARNING: page fault at 7fff63301000 gcore: WARNING: page fault at 7fff63302000 gcore: WARNING: page fault at 7fff63303000 gcore: WARNING: page fault at 7fff63304000 gcore: WARNING: page fault at 7fff63305000 Saved core.1951.system_crash crash> In fact, no swap was used at all: crash> swap FILENAME TYPE SIZE USED PCT PRIORITY /dm-1 PARTITION 5439480k 0k 0% -1 crash> And here are the "page fault" pages from above, all either unreferenced file-backed pages or unreferenced data pages: crash> vm -p ... [ cut ] ... VIRTUAL PHYSICAL ... [ cut ] ... 386df98000 FILE: /lib64/libc-2.12.so OFFSET: 198000 386df99000 FILE: /lib64/libc-2.12.so OFFSET: 199000 ... [ cut ] ... 386df9e000 (not mapped) 386df9f000 (not mapped) ... [ cut ] ... 7fff632f3000 (not mapped) 7fff632f4000 (not mapped) 7fff632f5000 (not mapped) 7fff632f6000 (not mapped) 7fff632f7000 (not mapped) 7fff632f8000 (not mapped) 7fff632f9000 (not mapped) 7fff632fa000 (not mapped) 7fff632fb000 (not mapped) 7fff632fc000 (not mapped) 7fff632fd000 (not mapped) 7fff632fe000 (not mapped) 7fff632ff000 (not mapped) 7fff63300000 (not mapped) 7fff63301000 (not mapped) 7fff63302000 (not mapped) 7fff63303000 (not mapped) 7fff63304000 (not mapped) 7fff63305000 (not mapped) ... Dave

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

HATAYAMA, Daisuke From: Lei Wen <adrian.wenl(a)gmail.com&gt; Subject: [Crash-utility] [PATCH] add arm support for libgcore Date: Mon, 13 Feb 2012 09:32:34 +0800 > Hi, > > Current the crash utility has the support for extracting core dump > image from original kdump file: > http://people.redhat.com/anderson/extensions/gcore_help_gcore.html > > But it only supports x86 and x86_64 now. > I add one supporting patch to port it to ARM and another fix a minor > bug in original implementation. > > Best regards, > Lei