It has been suggested already, and is certain now, that the problem actually
happens under high network load, probably if the network connection is more or
less saturated: I can reproduce it pretty reliably by running gv with a very
large PS figure ( http://dept-info.labri.fr/~thibault/tmp/graph-radial.ps ) on
a remote X server in my local network.

I also confirmed my guess that the problem is related to the gnumach BPF patch:
A kernel without the patch works, an otherwise identical kernel with the patch
(and the updated pfinet) crashes.

With the kernel debugger, I was able to find out that the crash actually
happens in the line

   _last->ikm_next = (kmsg);

in ipc_kmsg_enqueue_macro() (ipc/ipc_kmsg.h), because _last has the value
IKM_BOGUS. It turns out ipc_kmsg_enqueue() is called with a broken
ipc_kmsg_queue as "queue" parameter: It's head points to an element with "next"
and "prev" pointers both set to IKM_BOGUS.

However, I was not able to find out how this broken ipc_kmsg_queue gets
created. Probably some locking issue in device/net_io.c or so, but that's just
guessing. One possibility for such a broken queue to be created could be if
ipc_kmsg_rmqueue_first_macro() or ipc_kmsg_rmqueue() is called with a "queue"
parameter which doesn't actually point to the queue in which the kmsg entry is:
In this case, the "next" and "prev" pointers of the entry would get set to
IKM_BOGUS, but the head pointer of the queue wouldn't get updated accordingly.

-antrik-


(file #11971)

While compiling a package, I just hit a ``General Protection Trap''.

#v+
$ addr2line -f -e gnumach 0x10d117
ipc_kmsg_enqueue
../ipc/ipc_kmsg.c:83
#v-

ipc/ipc_kmsg.c
#v+
[...]
    78  void
    79  ipc_kmsg_enqueue(
    80          ipc_kmsg_queue_t        queue,
    81          ipc_kmsg_t              kmsg)
    82  {
    83          ipc_kmsg_enqueue_macro(queue, kmsg);
    84  }
[...]
#v-