Hi Dave, > > 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) > > 7fff63304000 (not mapped) > > 7fff63305000 (not mapped) > > ... > > > > Dave > > > > Thanks for complement, Dave. This is exactly my case. :) On my board, the swap is actually not enabled. > > 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. Hatayama, I think if the gcore extension with such capability would be a great assistant tool. But it seems not hurry for now to implement it. BTW, does the "not mapped" pages mean those page just be hold by the process, but the process not use it yet. So fill those pages with zero seems no harm to me. :) > > Thanks. > HATAYAMA, Daisuke Thanks, Lei -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
