Hi Gilles, I'm pushing your findings to the list, also as my colleagues showed strong interest - this thing may explain rare corruptions for us as well.
I thought a bit about that likely u_mode-related crash in your test case and have the following theory so far: If the xeno_current_mode storage is allocated on the application heap (!HAVE_THREAD, that's also what we are forced to use), it is automatically freed on thread termination in the context of the dying thread. If the thread is already migrated to secondary or if that happens while it is cleaned up (i.e. before calling for exit into the kernel), there is no problem, Xenomai will not touch the mode storage anymore. But if the thread happens to delete the storage "silently", without any migration, the final exit will trigger one further access. And that takes place against an invalid head area at this point. Does this make sense? If that is true, all we need to do is to force a migration before releasing the mode storage. Could you check this? Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core