> > Found this in /proc/kmsg (and on my console):
> > <1>Unable to handle kernel NULL pointer dereference at virtual address c000010c
> The offending function is exit_notify:
> if (task[smp_num_cpus] && task[smp_num_cpus] != current) /* init */
> p->p_pptr = task[smp_num_cpus];
> else
> p->p_pptr = task[0];
> p->p_osptr = p->p_pptr->p_cptr;
> ^^^^^^^^^^^^^^^^^ <---- NULL pointer,
> dereferenced one line down
> p->p_osptr->p_ysptr = p;
> p->p_pptr->p_cptr = p;
> Hmm... init with no children? Makes sense if the dying bash was the only
> one (single user mode at boot-up). Perhaps a check for this wouldn't be
> such a bad idea. But then, why did bash decide to die in the first place?
> Any ideas?
I often boot Linux (2.0.27) in a single-user mode: I need to passthru a lot
of pictures every day, and have only 8 mb ram - so X in singleuser + xv - is
perfect.
But seems, that Linux does not like singleuiser. In multiuser, I receive
opses very seldom on the console (well, thats began from 2.0.23 - earlier, I
never seen any ops), and in singleuser - one per hour. Or, if not ops,
xv dies - it dies with segmentation fault, or deadly hangs X.
I know what causes xv & X die in singleuser. Maybe, it's the one. xv has a
memory leak (3.10 in my case), and after ~10mb pictures, 10mb swap is filled
with shit. :) When the swap-space is out, system crashes or hangs, or kills
xv. BTW, the behaviour is another when in multiuser - seems, that X + xv
does not have memory leak then. :()
> Ionut