Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Wed, 21 Jun 2017 16:36:27 +0200

On 06/21/2017 04:01 PM, Heinz Junkes wrote:
> Is there a reason why e.g. in src/libCom/log/logClient.c 
> 
> at most places 
> fprintf (stderr, “ error message …”);
> or even 
> printf (“ error message “);
> 
> is used instead errlogPrintf which uses the errlog-thread (low prio)

These function are called when new input is logged via errlogPrintf()
(through errlog-thread).  If they in turn call errlogPrintf() on error,
this will result in some recursion.

> This is just one place that I noticed today. I guess this is usually implemented in this way.

This is a special case.  There are similar dangers if eg. functions
called within errlogInit() or errlogPrintf() try to log errors.

So errors resulting from log messages should be reported directly to
stdout/stderr.

> But with RTEMS the output on the console is mixed up and not readable anymore.
> 
> …
> ok 27 - pvt.count (8) == N+1 (8)
> ok 28 - Removed 1 listener
> # Testing iocLogPrefix
> # Listening on port 1026
> ok 29 - iocLogInit() == 0
> ok 30 - Accepted lnoegw  cclliieenntt:
>  ocko n3n1e c-t eCdl iteon tl orge asde rcvoenrf iagtu r"e1d2
> 7.0.0.1:1026"
> ok 32 - prefix matches
> ...

Ha, seems like stdout and stderr are getting mux'd in an unfortunate,
though amusing, way.  This must be a feature of newer rtems/newlib as
4.9 and 4.10 don't do this.  At a guess, some stdio locking has been
made more granular, or removed.

from rtems 4.9.6/pc386

> ok 27 - pvt.count (8) == N+1 (8)
> ok 28 - Removed 1 listener
> # Testing iocLogPrefix
> # Listening on port 1026
> ok 29 - iocLogInit() == 0
> ok 30 - Accepted new client
> ok 31 - Client read configured
> log client: connected to log server at "127.0.0.1:1026"
> ok 32 - prefix matches

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System