Re: [Xenomai-core] [BUG?] registry usage + module removal causes kernel oops (xenomai native)

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

Thomas Wiedemann wrote:
> Hi again,
> 
> I observed another wrong(?) behaviour of xenomai, caused by a wrong
> behaviour in our code :) The resources (tested with mutexes) are not
> deleted after the process which created them exits without cleaning up
> (for example, it crashes).
> 
> For anonymous objects, i don't see a reason why this would be a
> defined behaviour, since there is no way to reuse those objects.
> Therefore, I consider this to be a bug, as it will finally eat up all 
> memory.
> Or are there any technical reasons for this?

-ENOTIMPLEMENTEDYET

We have this desired auto-cleanup for the POSIX skin already, but we are
lacking it for the others. The native objects should be straightforward,
stalled RTDM handles still require a bit thoughts (and the solution of
another issue). Time will come.

For now we here help ourselves by keeping track of those resources in
userspace at framework level and release them - when required - inside a
SEGFAULT signal handler. Of course, covers not all faults.

> 
> Another bug appeared for objects registered at the registry. When
> using xeno-native and xeno-rtdm, the order of removal seems to be
> important. I appended a small code sample to register a mutex at
> the registry. After the program exits, the modules can not be unloaded
> in the order
>   1) xeno-native
>   2) xeno-rtdm,
> but the other way around works fine. Instead, rmmod ends up with a
> segmentation fault, dmesg output appended.
> 
> I tested this on xenomai 2.3.0/linux 2.6.19 and 2.2.5-svn/linux2.6.17.14.
> 

Looks like it's related to the left-over mutex in the registry. Probably
the other order just papers the issue. $Someone should give your code a
try, maybe I can check later with a debugger.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]