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