Re: [Xenomai-help] Re : rt_printf with daemonized task

Re: [Xenomai-help] Re : rt_printf with daemonized task

[oliver.schlenker]

-------- Original Message --------
Subject: Re: Re : rt_printf with daemonized task (08-Okt-2009 14:19)
From:    Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To:      oliver.schlenker@smmotioncontrol.de

> Jan Kiszka wrote:
> > Gilles Chanteperdrix wrote:
> >> Jan Kiszka wrote:
> >>> Gilles Chanteperdrix wrote:
> >>>> oliver.schlenker@smmotioncontrol.de wrote:
> >>>>>>> int main( int arc, char *argv[] ) { int i;
> >>>>>>>
> >>>>>>> rt_print_auto_init(1);
> >>>>>>>
> >>>>>>> rt_printf("--------------- TEST RT-PRINTF  1 ------------\n");
> >>>>>>>
> >>>>>>> sleep(1);
> >>>>>>>
> >>>>>>> daemon(0,0);
> >>>>>>>
> >>>>>>> rt_print_auto_init(1);
> >>>>> Ok, understood, at least for the scenario where the rt_print feature
> >>>>> is initialised befor the fork/daemon call. What I don't understand
> >>>>> is, why it does not work if the rt_print feature is initialised after
> >>>>> the fork / daemon.
> >>>> From the way I understand your code, you never tried to initialize the
> >>>> rt_print feature only after the fork, your code initializes it both
> >>>> before and after.
> >>>>
> >>> There are two initializations: The base init done via __rt_print_init 
> on
> >>> library loading and the one to be done per-thread via rt_print_init (or
> >>> on first rt_printf). That printer thread is initialized via the former
> >>> one. On fork, we do not need to re-run the full __rt_print_init
> >>> (variables and resources are cloned on fork), we just need to spawn
> >>> another printer thread.
> >> Unless I am wrong, rtdk also maintains a list of the thread buffers
> >> which need to be polled. After the fork, this list will be intact, but
> >> the threads to which belong the buffers will no longer exist. So, IMO,
> >> the fork handler should also free all these buffers and reset the list
> >> to the empty state.
> > 
> > Famous last words: That should work without tweaking. A print_buffer
> > only contains data references, nothing that points to some uncloned thread.
> 
> Ok. But you walk the list of print_buffers every time, and these
> print_buffers remain allocated in the child process. So, that is a kind
> of memory leak.
> 
> > 
> > Jan
> > 
> 
> 
> -- 
>                                           Gilles
> 

Did change my test code in the meantime to :


#include <stdlib.h>
#include <stdio.h>

#include <native/task.h>
#include <native/timer.h>
#include <rtdk.h>


int main( int arc, char *argv[] )
{
int i;

daemon(0,1);

__rt_print_init();

rt_print_auto_init(1);

rt_printf("--------------- TEST RT-PRINTF ------------\n");

sleep(10);

return(0);
}


and everything works fine at first glance.

There is at least an output to syslog of the rt_printf message. I have
no idea if this creates an internal memory leak. For my application
it might be not a real problem, because the fork is done only once.
For application with several fork calls or a recursional fork calls it might be
not ok.


Oliver




To: gilles.chanteperdrix@xenomai.org
    jan.kiszka@siemens.com
Cc: xenomai-help@gna.org

Re: [Xenomai-help] Re : rt_printf with daemonized task

[Jan Kiszka]

oliver.schlenker@domain.hid wrote:
> 
> 
> 
> 
> -------- Original Message --------
> Subject: Re: Re : rt_printf with daemonized task (08-Okt-2009 14:19)
> From:    Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> To:      oliver.schlenker@domain.hid
> 
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> oliver.schlenker@domain.hid wrote:
>>>>>>>>> int main( int arc, char *argv[] ) { int i;
>>>>>>>>>
>>>>>>>>> rt_print_auto_init(1);
>>>>>>>>>
>>>>>>>>> rt_printf("--------------- TEST RT-PRINTF  1 ------------\n");
>>>>>>>>>
>>>>>>>>> sleep(1);
>>>>>>>>>
>>>>>>>>> daemon(0,0);
>>>>>>>>>
>>>>>>>>> rt_print_auto_init(1);
>>>>>>> Ok, understood, at least for the scenario where the rt_print feature
>>>>>>> is initialised befor the fork/daemon call. What I don't understand
>>>>>>> is, why it does not work if the rt_print feature is initialised after
>>>>>>> the fork / daemon.
>>>>>> From the way I understand your code, you never tried to initialize the
>>>>>> rt_print feature only after the fork, your code initializes it both
>>>>>> before and after.
>>>>>>
>>>>> There are two initializations: The base init done via __rt_print_init 
>> on
>>>>> library loading and the one to be done per-thread via rt_print_init (or
>>>>> on first rt_printf). That printer thread is initialized via the former
>>>>> one. On fork, we do not need to re-run the full __rt_print_init
>>>>> (variables and resources are cloned on fork), we just need to spawn
>>>>> another printer thread.
>>>> Unless I am wrong, rtdk also maintains a list of the thread buffers
>>>> which need to be polled. After the fork, this list will be intact, but
>>>> the threads to which belong the buffers will no longer exist. So, IMO,
>>>> the fork handler should also free all these buffers and reset the list
>>>> to the empty state.
>>> Famous last words: That should work without tweaking. A print_buffer
>>> only contains data references, nothing that points to some uncloned thread.
>> Ok. But you walk the list of print_buffers every time, and these
>> print_buffers remain allocated in the child process. So, that is a kind
>> of memory leak.
>>
>>> Jan
>>>
>>
>> -- 
>>                                           Gilles
>>
> 
> Did change my test code in the meantime to :
> 
> 
> #include <stdlib.h>
> #include <stdio.h>
> 
> #include <native/task.h>
> #include <native/timer.h>
> #include <rtdk.h>
> 
> 
> int main( int arc, char *argv[] )
> {
> int i;
> 
> daemon(0,1);
> 
> __rt_print_init();
> 
> rt_print_auto_init(1);
> 
> rt_printf("--------------- TEST RT-PRINTF ------------\n");
> 
> sleep(10);
> 
> return(0);
> }
> 
> 
> and everything works fine at first glance.
> 
> There is at least an output to syslog of the rt_printf message. I have
> no idea if this creates an internal memory leak. For my application
> it might be not a real problem, because the fork is done only once.
> For application with several fork calls or a recursional fork calls it might be
> not ok.

This case will not leak as there were no buffers registered before the
fork. But it's not a generic solution, using a non-public service,
__rt_print_init, which I don't want to make public.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Re : rt_printf with daemonized task

[Gilles Chanteperdrix]

oliver.schlenker@domain.hid wrote:
> Did change my test code in the meantime to :
> 
> 
> #include <stdlib.h>
> #include <stdio.h>
> 
> #include <native/task.h>
> #include <native/timer.h>
> #include <rtdk.h>
> 
> 
> int main( int arc, char *argv[] )
> {
> int i;
> 
> daemon(0,1);
> 
> __rt_print_init();
> 
> rt_print_auto_init(1);
> 
> rt_printf("--------------- TEST RT-PRINTF ------------\n");
> 
> sleep(10);
> 
> return(0);
> }
> 
> 
> and everything works fine at first glance.
> 
> There is at least an output to syslog of the rt_printf message. I have
> no idea if this creates an internal memory leak. For my application
> it might be not a real problem, because the fork is done only once.
> For application with several fork calls or a recursional fork calls it might be
> not ok.

Calling fork inside an application which has several running threads is
already insane. Think about it: if the running threads had a mutex
locked, the mutex will still appear as locked in the child process and
can not be unlocked. The threads will not exist in the child process,
but their stacks and allocated tsd will still exists. posix proposes
pthread_atfork to solve these issues, but not forking in a process with
threads is more sane (the exception being to call fork+exec or
vfork+exec, since in that case the virtual memory space will be wiped
out by exec, so we do not care about the leaks anyway).

-- 
                                          Gilles

[Xenomai-help] Re : rt_printf with daemonized task

[oliver.schlenker]

-------- Original Message --------
Subject: Re: Re-8:  rt_printf with daemonized task (07-Okt-2009 17:38)
From:    Jan Kiszka <jan.kiszka@siemens.com>
To:      oliver.schlenker@smmotioncontrol.de

> oliver.schlenker@smmotioncontrol.de wrote:
> > 
> > 
> > As you expected, changing the syslog call from
> >     syslog( LOG_ERR | LOG_LOCAL4, head->text ); 
> > to
> >     syslog( LOG_ERR | LOG_LOCAL4, "%s", head->text ); 
> > 
> > did not change anything.
> > 
> > To track down the problem further, I have made a small test application :
> > 
> > #include <stdlib.h>
> > #include <stdio.h>
> > 
> > #include <native/task.h>
> > #include <native/timer.h>
> > #include <rtdk.h>
> > 
> > 
> > int main( int arc, char *argv[] )
> > {
> > int i;
> > 
> > rt_print_auto_init(1);
> > 
> > rt_printf("--------------- TEST RT-PRINTF  1 ------------\n");
> > 
> > 	sleep(1);
> > 
> > daemon(0,0);
> > 
> > 	rt_print_auto_init(1);
> > 
> > 	rt_printf("--------------- TEST RT-PRINTF  2 ------------\n");
> > 
> > 	sleep(10);
> > 
> > return(0);
> > }
> > 
> > 
> > 
> > This application gives the following results :
> > - If the daemon() function is not called, all rt_printf() do work well
> >   and output is shown in syslog
> > - If daemon() function is called, and first call to sleep(1) is omitted,
> >   there is no output in the syslog whatsoever.
> > - If daemon() function is called, and first call to sleep(1) is executed,
> >   there is output of the first rt_printf in the syslog but not of the 
> > second
> >   one.
> > 
> > I do not have any idea why daemonizing of the process is not giving
> > any output to the syslog.
> 
> As you are already looking at rt_printf.c: __rt_print_init spawns a
> pthread that polls the internal queues and issues the output to stdout
> or whatever. On fork (or daemonize), this thread is not replicated. So
> the child process simply has no printing thread.

Ok, understood, at least for the scenario where the rt_print feature is initialised
befor the fork/daemon call.
What I don't understand is, why it does not work if the rt_print feature is initialised after the fork / daemon.

> 
> I think this should be fixable with a pthread_atfork hook, patches
> always welcome.

I would like to follow up this track. I have to have a look at pthread_atfork first,
because I'm not so familiar with the pthread functions.
Therefor any hint what should be done with pthread_atfork is very welcome.


> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux



Oliver

To: jan.kiszka@siemens.com
Cc: gilles.chanteperdrix@xenomai.org
    xenomai-help@gna.org

Re: [Xenomai-help] Re : rt_printf with daemonized task

[Gilles Chanteperdrix]

oliver.schlenker@domain.hid wrote:
>>> int main( int arc, char *argv[] ) { int i;
>>> 
>>> rt_print_auto_init(1);
>>> 
>>> rt_printf("--------------- TEST RT-PRINTF  1 ------------\n");
>>> 
>>> sleep(1);
>>> 
>>> daemon(0,0);
>>> 
>>> rt_print_auto_init(1);
> Ok, understood, at least for the scenario where the rt_print feature
> is initialised befor the fork/daemon call. What I don't understand
> is, why it does not work if the rt_print feature is initialised after
> the fork / daemon.

>From the way I understand your code, you never tried to initialize the
rt_print feature only after the fork, your code initializes it both
before and after.

-- 
                                          Gilles

Re: [Xenomai-help] Re : rt_printf with daemonized task

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> oliver.schlenker@domain.hid wrote:
>>>> int main( int arc, char *argv[] ) { int i;
>>>>
>>>> rt_print_auto_init(1);
>>>>
>>>> rt_printf("--------------- TEST RT-PRINTF  1 ------------\n");
>>>>
>>>> sleep(1);
>>>>
>>>> daemon(0,0);
>>>>
>>>> rt_print_auto_init(1);
>> Ok, understood, at least for the scenario where the rt_print feature
>> is initialised befor the fork/daemon call. What I don't understand
>> is, why it does not work if the rt_print feature is initialised after
>> the fork / daemon.
> 
> From the way I understand your code, you never tried to initialize the
> rt_print feature only after the fork, your code initializes it both
> before and after.
> 

There are two initializations: The base init done via __rt_print_init on
library loading and the one to be done per-thread via rt_print_init (or
on first rt_printf). That printer thread is initialized via the former
one. On fork, we do not need to re-run the full __rt_print_init
(variables and resources are cloned on fork), we just need to spawn
another printer thread.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Re : rt_printf with daemonized task

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> oliver.schlenker@domain.hid wrote:
>>>>> int main( int arc, char *argv[] ) { int i;
>>>>>
>>>>> rt_print_auto_init(1);
>>>>>
>>>>> rt_printf("--------------- TEST RT-PRINTF  1 ------------\n");
>>>>>
>>>>> sleep(1);
>>>>>
>>>>> daemon(0,0);
>>>>>
>>>>> rt_print_auto_init(1);
>>> Ok, understood, at least for the scenario where the rt_print feature
>>> is initialised befor the fork/daemon call. What I don't understand
>>> is, why it does not work if the rt_print feature is initialised after
>>> the fork / daemon.
>> From the way I understand your code, you never tried to initialize the
>> rt_print feature only after the fork, your code initializes it both
>> before and after.
>>
> 
> There are two initializations: The base init done via __rt_print_init on
> library loading and the one to be done per-thread via rt_print_init (or
> on first rt_printf). That printer thread is initialized via the former
> one. On fork, we do not need to re-run the full __rt_print_init
> (variables and resources are cloned on fork), we just need to spawn
> another printer thread.

Unless I am wrong, rtdk also maintains a list of the thread buffers
which need to be polled. After the fork, this list will be intact, but
the threads to which belong the buffers will no longer exist. So, IMO,
the fork handler should also free all these buffers and reset the list
to the empty state.

-- 
                                          Gilles

Re: [Xenomai-help] Re : rt_printf with daemonized task

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> oliver.schlenker@domain.hid wrote:
>>>>>> int main( int arc, char *argv[] ) { int i;
>>>>>>
>>>>>> rt_print_auto_init(1);
>>>>>>
>>>>>> rt_printf("--------------- TEST RT-PRINTF  1 ------------\n");
>>>>>>
>>>>>> sleep(1);
>>>>>>
>>>>>> daemon(0,0);
>>>>>>
>>>>>> rt_print_auto_init(1);
>>>> Ok, understood, at least for the scenario where the rt_print feature
>>>> is initialised befor the fork/daemon call. What I don't understand
>>>> is, why it does not work if the rt_print feature is initialised after
>>>> the fork / daemon.
>>> From the way I understand your code, you never tried to initialize the
>>> rt_print feature only after the fork, your code initializes it both
>>> before and after.
>>>
>> There are two initializations: The base init done via __rt_print_init on
>> library loading and the one to be done per-thread via rt_print_init (or
>> on first rt_printf). That printer thread is initialized via the former
>> one. On fork, we do not need to re-run the full __rt_print_init
>> (variables and resources are cloned on fork), we just need to spawn
>> another printer thread.
> 
> Unless I am wrong, rtdk also maintains a list of the thread buffers
> which need to be polled. After the fork, this list will be intact, but
> the threads to which belong the buffers will no longer exist. So, IMO,
> the fork handler should also free all these buffers and reset the list
> to the empty state.

Famous last words: That should work without tweaking. A print_buffer
only contains data references, nothing that points to some uncloned thread.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Re : rt_printf with daemonized task

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> oliver.schlenker@domain.hid wrote:
>>>>>>> int main( int arc, char *argv[] ) { int i;
>>>>>>>
>>>>>>> rt_print_auto_init(1);
>>>>>>>
>>>>>>> rt_printf("--------------- TEST RT-PRINTF  1 ------------\n");
>>>>>>>
>>>>>>> sleep(1);
>>>>>>>
>>>>>>> daemon(0,0);
>>>>>>>
>>>>>>> rt_print_auto_init(1);
>>>>> Ok, understood, at least for the scenario where the rt_print feature
>>>>> is initialised befor the fork/daemon call. What I don't understand
>>>>> is, why it does not work if the rt_print feature is initialised after
>>>>> the fork / daemon.
>>>> From the way I understand your code, you never tried to initialize the
>>>> rt_print feature only after the fork, your code initializes it both
>>>> before and after.
>>>>
>>> There are two initializations: The base init done via __rt_print_init on
>>> library loading and the one to be done per-thread via rt_print_init (or
>>> on first rt_printf). That printer thread is initialized via the former
>>> one. On fork, we do not need to re-run the full __rt_print_init
>>> (variables and resources are cloned on fork), we just need to spawn
>>> another printer thread.
>> Unless I am wrong, rtdk also maintains a list of the thread buffers
>> which need to be polled. After the fork, this list will be intact, but
>> the threads to which belong the buffers will no longer exist. So, IMO,
>> the fork handler should also free all these buffers and reset the list
>> to the empty state.
> 
> Famous last words: That should work without tweaking. A print_buffer
> only contains data references, nothing that points to some uncloned thread.

Ok. But you walk the list of print_buffers every time, and these
print_buffers remain allocated in the child process. So, that is a kind
of memory leak.

> 
> Jan
> 


-- 
                                          Gilles

Re: [Xenomai-help] Re : rt_printf with daemonized task

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> oliver.schlenker@domain.hid wrote:
>>>>>>>> int main( int arc, char *argv[] ) { int i;
>>>>>>>>
>>>>>>>> rt_print_auto_init(1);
>>>>>>>>
>>>>>>>> rt_printf("--------------- TEST RT-PRINTF  1 ------------\n");
>>>>>>>>
>>>>>>>> sleep(1);
>>>>>>>>
>>>>>>>> daemon(0,0);
>>>>>>>>
>>>>>>>> rt_print_auto_init(1);
>>>>>> Ok, understood, at least for the scenario where the rt_print feature
>>>>>> is initialised befor the fork/daemon call. What I don't understand
>>>>>> is, why it does not work if the rt_print feature is initialised after
>>>>>> the fork / daemon.
>>>>> From the way I understand your code, you never tried to initialize the
>>>>> rt_print feature only after the fork, your code initializes it both
>>>>> before and after.
>>>>>
>>>> There are two initializations: The base init done via __rt_print_init on
>>>> library loading and the one to be done per-thread via rt_print_init (or
>>>> on first rt_printf). That printer thread is initialized via the former
>>>> one. On fork, we do not need to re-run the full __rt_print_init
>>>> (variables and resources are cloned on fork), we just need to spawn
>>>> another printer thread.
>>> Unless I am wrong, rtdk also maintains a list of the thread buffers
>>> which need to be polled. After the fork, this list will be intact, but
>>> the threads to which belong the buffers will no longer exist. So, IMO,
>>> the fork handler should also free all these buffers and reset the list
>>> to the empty state.
>> Famous last words: That should work without tweaking. A print_buffer
>> only contains data references, nothing that points to some uncloned thread.
> 
> Ok. But you walk the list of print_buffers every time, and these
> print_buffers remain allocated in the child process. So, that is a kind
> of memory leak.

Hmm, right. They should be freed in the child right after forking.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux