[Xenomai-core] Yet another ((weak)) bug

[Xenomai-core] Yet another ((weak)) bug

[Jan Kiszka]

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?

Jan

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

Re: [Xenomai-core] Yet another ((weak)) bug

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

Re: [Xenomai-core] Yet another ((weak)) bug

[Jan Kiszka]

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.

Jan

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

Re: [Xenomai-core] Yet another ((weak)) bug

[Gilles Chanteperdrix]

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.

Actually, xeno_skin_bind_opt should call pthread_atfork, since the child
 process should be bound again, whatever the skin.

-- 
					    Gilles.

Re: [Xenomai-core] Yet another ((weak)) bug

[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.
> 
> Actually, xeno_skin_bind_opt should call pthread_atfork, since the child
>  process should be bound again, whatever the skin.

That's a another thing, but it's true. First of all I just pushed a fix
for the sem_heap issue that makes our test case happy.

Jan

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

Re: [Xenomai-core] Yet another ((weak)) bug

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] Yet another ((weak)) bug

[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

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

Re: [Xenomai-core] Yet another ((weak)) bug

[Stefan Kisdaroczi]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: [Xenomai-core] Yet another ((weak)) bug

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

Re: [Xenomai-core] Yet another ((weak)) bug

[Jan Kiszka]

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

Re: [Xenomai-core] Yet another ((weak)) bug

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] Yet another ((weak)) bug

[Jan Kiszka]

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.

Jan

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

Re: [Xenomai-core] Yet another ((weak)) bug

[Gilles Chanteperdrix]

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.

> 
> Jan
> 


-- 
					    Gilles.

Re: [Xenomai-core] Yet another ((weak)) bug

[Jan Kiszka]

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

Re: [Xenomai-core] Yet another ((weak)) bug

[Gilles Chanteperdrix]

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.