Hi Gilles,

this one requires some fixing too:

xeno_sem_heap is marked weak. xeno_init_sem_heaps is called once per
initialized skin. It unmaps any existing heap and creates a new one.
That's already fragile during constructor run, but it's lethal during
process runtime, ie. when using dlopen.

I think the solution is to handle forks separately and only remap in
that case. Digging in this direction now.

BTW, what triggers the re-run of xeno_init_sem_heaps after a fork so far?


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to