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

Yet another reason to address auto-cleanup soon: I thought to remember
the native skin keeps track of resources in a global list and kills them
on rmmod, but that's only true for a few.

Instead stalled named resources are kept in the registry. On
unregistration of the last skin xnregistry_cleanup() is called. It tries
to kill the stalled entries from proc but their roots may have already
been removed (here: the native skin's proc root).

Philippe, this makes the sweep loop in xnregistry_cleanup rather fragile
and of questionable use. I guess all skins have to handle this on their
own, and we should just bark loudly here if something remained.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to