Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Jan Kiszka wrote:
> Thomas Wiedemann wrote:
> 
>>Hi,
>>
>>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 2.6.17.8, 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.

-- 
                                                 Gilles Chanteperdrix