Re: [Xenomai-core] Yet another ((weak)) bug
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Stefan Kisdaroczi wrote: Am 12.02.2010 17:22, schrieb Jan Kiszka: libxnskin or so? Jan libxenomai ? Ok. Let's go for libxenomai. I will try and do that in the next few days. Already had a chance to look into this? No. I was off a few days. I just looked at it in the train, but could not test it yet. If there is anything I can do to help accelerating it, please let me know. We need to bake a new Xenomai package this week for our customer, and at some point I need to decide between upstream and my temporary fix. Upstream is generally preferred - if available. Yes, I have been a bit delayed, but should handle this this week, so as to be ready for a release next week-end. Anything in some private branch already? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Yet another ((weak)) bug
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Stefan Kisdaroczi wrote: Am 12.02.2010 17:22, schrieb Jan Kiszka: libxnskin or so? Jan libxenomai ? Ok. Let's go for libxenomai. I will try and do that in the next few days. Already had a chance to look into this? No. I was off a few days. I just looked at it in the train, but could not test it yet. If there is anything I can do to help accelerating it, please let me know. We need to bake a new Xenomai package this week for our customer, and at some point I need to decide between upstream and my temporary fix. Upstream is generally preferred - if available. Yes, I have been a bit delayed, but should handle this this week, so as to be ready for a release next week-end. Anything in some private branch already? Ok. Everything pushed. It works on ARM and x86. I have not tested in the multilib and/or dlopen case, so please test it if you can. Jan -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Yet another ((weak)) bug
Gilles Chanteperdrix wrote: Stefan Kisdaroczi wrote: Am 12.02.2010 17:22, schrieb Jan Kiszka: libxnskin or so? Jan libxenomai ? Ok. Let's go for libxenomai. I will try and do that in the next few days. Already had a chance to look into this? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Yet another ((weak)) bug
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Stefan Kisdaroczi wrote: Am 12.02.2010 17:22, schrieb Jan Kiszka: libxnskin or so? Jan libxenomai ? Ok. Let's go for libxenomai. I will try and do that in the next few days. Already had a chance to look into this? No. I was off a few days. I just looked at it in the train, but could not test it yet. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Yet another ((weak)) bug
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: 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? It must be done for the child process to get a private heap different from the parent process. I would guess it is handled by pthread_atfork. Ah, only the POSIX skin does that. However, sem-heaps must not be POSIX-only. OK, patch in the make. Ok. I am thinking more and more that you are right about making libxeno_common a standalone library. Only the name stinks, we should find a better one. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Yet another ((weak)) bug
Am 12.02.2010 17:22, schrieb Jan Kiszka: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: 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? It must be done for the child process to get a private heap different from the parent process. I would guess it is handled by pthread_atfork. Ah, only the POSIX skin does that. However, sem-heaps must not be POSIX-only. OK, patch in the make. Ok. I am thinking more and more that you are right about making libxeno_common a standalone library. Only the name stinks, we should find a better one. libxnskin or so? Jan libxenomai ? Stefan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
