[Xenomai-core] [bug] user memory leakage on rt_task_delete

[Xenomai-core] [bug] user memory leakage on rt_task_delete

[Jan Kiszka]

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

Hi all,

during my ongoing search for the init/cleanup issue of shadow threads, I
stumbled over another problem: Deleting a userspace native thread that
is blocked in primary mode does not let the NPTL clean up all resources
allocated in userspace. If you plan to do some rt_task_create/delete in
a loop, you will soon run out of memory (and Mr. oom-killer will show
up...).

I haven't found a solution for this beyond letting a rt-task always
terminate itself (or terminate the whole program after forced
deletions). If there is no solution, we should at least document this
fact somewhere.

Again, it's not a common use case, but it's also not an expectable
behaviour of the native skin.

Ok, back to work,
Jan


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

Re: [Xenomai-core] [bug] user memory leakage on rt_task_delete

[Philippe Gerum]

Jan Kiszka wrote:
> Hi all,
> 
> during my ongoing search for the init/cleanup issue of shadow threads, I
> stumbled over another problem: Deleting a userspace native thread that
> is blocked in primary mode does not let the NPTL clean up all resources
> allocated in userspace. If you plan to do some rt_task_create/delete in
> a loop, you will soon run out of memory (and Mr. oom-killer will show
> up...).
> 
> I haven't found a solution for this beyond letting a rt-task always
> terminate itself (or terminate the whole program after forced
> deletions). If there is no solution, we should at least document this
> fact somewhere.
> 
> Again, it's not a common use case, but it's also not an expectable
> behaviour of the native skin.
> 

I see no possible workaround to allow a shadow thread deletion from 
kernel space while still leaving the opportunity for the NPTL thread to 
perform some user-space cleanups; recycling a previous Xenomai context 
to unwind a Linux context would lead to some terminally broken 
situation, so the nucleus must reap the terminated shadow at kernel 
level asap. However, the rt_task_delete() wrapper from the user-space 
support library might preferably pthread_kill() the thread, instead of 
asking the nucleus for that purpose.

-- 

Philippe.

Re: [Xenomai-core] [bug] user memory leakage on rt_task_delete

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi all,
>>
>> during my ongoing search for the init/cleanup issue of shadow threads, I
>> stumbled over another problem: Deleting a userspace native thread that
>> is blocked in primary mode does not let the NPTL clean up all resources
>> allocated in userspace. If you plan to do some rt_task_create/delete in
>> a loop, you will soon run out of memory (and Mr. oom-killer will show
>> up...).
>>
>> I haven't found a solution for this beyond letting a rt-task always
>> terminate itself (or terminate the whole program after forced
>> deletions). If there is no solution, we should at least document this
>> fact somewhere.
>>
>> Again, it's not a common use case, but it's also not an expectable
>> behaviour of the native skin.
>>
> 
> I see no possible workaround to allow a shadow thread deletion from
> kernel space while still leaving the opportunity for the NPTL thread to
> perform some user-space cleanups; recycling a previous Xenomai context
> to unwind a Linux context would lead to some terminally broken
> situation, so the nucleus must reap the terminated shadow at kernel
> level asap. However, the rt_task_delete() wrapper from the user-space
> support library might preferably pthread_kill() the thread, instead of
> asking the nucleus for that purpose.

Hmm, I think I've read something about signal delivery and handling in
threads which said that the delivery is per thread, but the handling
remains to affect the whole process. Thus, I'm afraid we may kill
ourselves here and not just the thread...

Ok, Versuch macht klug (in English: just give it a try)!

Jan


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

Re: [Xenomai-core] [bug] user memory leakage on rt_task_delete

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Hi all,
>>>
>>>during my ongoing search for the init/cleanup issue of shadow threads, I
>>>stumbled over another problem: Deleting a userspace native thread that
>>>is blocked in primary mode does not let the NPTL clean up all resources
>>>allocated in userspace. If you plan to do some rt_task_create/delete in
>>>a loop, you will soon run out of memory (and Mr. oom-killer will show
>>>up...).
>>>
>>>I haven't found a solution for this beyond letting a rt-task always
>>>terminate itself (or terminate the whole program after forced
>>>deletions). If there is no solution, we should at least document this
>>>fact somewhere.
>>>
>>>Again, it's not a common use case, but it's also not an expectable
>>>behaviour of the native skin.
>>>
>>
>>I see no possible workaround to allow a shadow thread deletion from
>>kernel space while still leaving the opportunity for the NPTL thread to
>>perform some user-space cleanups; recycling a previous Xenomai context
>>to unwind a Linux context would lead to some terminally broken
>>situation, so the nucleus must reap the terminated shadow at kernel
>>level asap. However, the rt_task_delete() wrapper from the user-space
>>support library might preferably pthread_kill() the thread, instead of
>>asking the nucleus for that purpose.
> 
> 
> Hmm, I think I've read something about signal delivery and handling in
> threads which said that the delivery is per thread, but the handling
> remains to affect the whole process. Thus, I'm afraid we may kill
> ourselves here and not just the thread...
> 

If the signal ends up being lethal, yes. All threads would be wiped out. 
  I was thinking of catching a signal to perform a per-thread cleanup 
over the terminated context and pthread_exit later on.

> Ok, Versuch macht klug (in English: just give it a try)!
> 
> Jan
> 


-- 

Philippe.

Re: [Xenomai-core] [bug] user memory leakage on rt_task_delete

[Jan Kiszka]

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

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Hi all,
>>>
>>> during my ongoing search for the init/cleanup issue of shadow threads, I
>>> stumbled over another problem: Deleting a userspace native thread that
>>> is blocked in primary mode does not let the NPTL clean up all resources
>>> allocated in userspace. If you plan to do some rt_task_create/delete in
>>> a loop, you will soon run out of memory (and Mr. oom-killer will show
>>> up...).
>>>
>>> I haven't found a solution for this beyond letting a rt-task always
>>> terminate itself (or terminate the whole program after forced
>>> deletions). If there is no solution, we should at least document this
>>> fact somewhere.
>>>
>>> Again, it's not a common use case, but it's also not an expectable
>>> behaviour of the native skin.
>>>
>> I see no possible workaround to allow a shadow thread deletion from
>> kernel space while still leaving the opportunity for the NPTL thread to
>> perform some user-space cleanups; recycling a previous Xenomai context
>> to unwind a Linux context would lead to some terminally broken
>> situation, so the nucleus must reap the terminated shadow at kernel
>> level asap. However, the rt_task_delete() wrapper from the user-space
>> support library might preferably pthread_kill() the thread, instead of
>> asking the nucleus for that purpose.
> 
> Hmm, I think I've read something about signal delivery and handling in
> threads which said that the delivery is per thread, but the handling
> remains to affect the whole process. Thus, I'm afraid we may kill
> ourselves here and not just the thread...
> 
> Ok, Versuch macht klug (in English: just give it a try)!
> 

Yep, as soon as the target thread was able to receive the signal, the
whole process can "enjoy" its effect.

What remains is to reserve one signal for the native skin and register a
handler on in to call pthread_exit. This should work, but leaves the
risk to collide with user defined signal handlers.

Jan


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