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/linux220.127.116.11. >> > > 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. Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core