Follow-up Comment #2, bug #18349 (project hurd):
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)
_______________________________________________________
Additional Item Attachment:
File name: gnumach-kmsg_assert.diff Size:4 KB
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?18349>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
