Sorry, forgot to reply all:
---------------------------
On Wed, 2010-08-18 at 20:57 +0000, Dave Anderson wrote:
> ----- "Bob Montgomery" <bob.montgomery@xxxxxx> wrote:
>
> > I'm working on a dump of a system that did not have a PID 1. I
don't
> > think it's relevant to the crash itself, but it does cause crash get
> > a seg fault.
> >
> > I don't know if it was important to have the context of pid 1 for
> > reporting mounts, or just any context, but this hack makes the
problem
> > go away, although not a very efficient way to find the lowest
existing
> > PID above 0.
>
> Yeah, it's not important to use the context of pid 1, but it just
needs
> some context, and I had presumed that init would always exist. I
thought
> that the panic("Attempted to kill the idle task!") in do_exit() would
> prevent pid 1 from ever going away -- but apparently your kernel
figured
> out how to do it elsewhere... ;-)
That test is for PID 0, not PID 1 (at least on the kernel I'm
debugging.) However, there is this also:
if (unlikely(tsk == child_reaper))
panic("Attempted to kill init!");
And child_reaper in the dump points to a task struct for init that isn't
in the ps listing. Hmmm. Maybe that part *is* interesting in this
dump...
>
> Your patch would pick a kernel thread pid, and apparently everything
still
> works OK? That being the case, it's fine with me.
With the patch, these commands all produce the same output:
crash-5.0.6-fix> mount >mount.out
crash-5.0.6-fix> mount -n 2 >mount2.out
crash-5.0.6-fix> mount -n 1459 >mount1459.out
I discovered the -n option as my first workaround.
Bob M.
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
