From: Dave Anderson <anderson@xxxxxxxxxx> Subject: Re: [PATCH] add arm support for libgcore Date: Wed, 15 Feb 2012 15:54:35 -0500 (EST) > > > ----- 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 > Thanks for complement, Dave. I overlooked lazy allocation case in my explanation... In this sense, the warning message might be unkind to users. Still, there's a way of checking each page's status by a variety of crash sub-commands. Lei, I think it's surely possible to reconstruct complete core dump from swap data if the swap partition is preserved entirely. Thanks. HATAYAMA, Daisuke -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
