Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>>Thomas Wiedemann wrote:
>>>there seems to be a bug in rt_task_create(). When no more memory is
>>>available, the module usage counter of xeno_native is decremented. I
>>>guess it is not incremented before, however, so the counter gets 0 and
>>>wraps then to a negative number. It is therefore not possible to remove
>>>the module.
>>>I appended a small program to demonstrate this. It simply eats up all
>>>memory from xenomai by registering as much mutexes as possible,
>>>and then tries to execute rt_task_create(), which fails. When started
>>>again, the bug occurs at rt_task_shadow(), as the mutexes have never
>>>been deleted.
>>>Compile with  gcc -O2 -Wall `xeno-config --xeno-cflags` `xeno-config
>>>--xeno-ldflags` -lrtdm -lnative -o rttest rttest.c
>>>then simply run it, and watch the output of lsmod before and after.
>>>Tested with xenomai 2.2.{0,5} and linux, modules loaded:
>>>xeno_native and xeno_nucleus.
>>Confirmed. Requires a closer look to find the leak path.
> Here is what happens: the task is created with the XNSHADOW bit, and
> destroyed before it was xnshadow_mapped, but the deletion hook calls
> xnshadow_unmap because the task has the XNSHADOW bit. And xnshadow_unmap
>  decrements the module count.

Here is an untested quick fix.

                                                 Gilles Chanteperdrix

Index: ksrc/nucleus/shadow.c
--- ksrc/nucleus/shadow.c	(révision 1930)
+++ ksrc/nucleus/shadow.c	(copie de travail)
@@ -888,6 +888,9 @@
 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
+	if (!xnshadow_thrptd(p))
+		return;
 	magic = xnthread_get_magic(thread);
 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
Xenomai-core mailing list

Reply via email to