[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #18349] GNU Mach: ``General Protection Trap'' in `ipc_kmsg_enqueue'

From: anonymous
Subject: [bug #18349] GNU Mach: ``General Protection Trap'' in `ipc_kmsg_enqueue'
Date: Mon, 12 Feb 2007 18:10:30 +0000
User-agent: Not mandatory, so FUCK YOU

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
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 )
a remote X server in my local network.

I also confirmed my guess that the problem is related to the gnumach BPF
A kernel without the patch works, an otherwise identical kernel with the
(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
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
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
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


(file #11971)

Additional Item Attachment:

File name: gnumach-kmsg_assert.diff       Size:4 KB


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]