Xymon Mailing List Archive search

rrd logs and graphs

list Jeremy Laidman
Wed, 11 Mar 2015 17:50:05 +1100
Message-Id: <user-d03e1be25a63@xymon.invalid>

Yes, apparently, "(null)" is what GNU's printf outputs when asked to print
a string pointer that is null.  The POSIX behaviour is not defined, and so
in some systems, it dumps core rather than detecting the illegal string.

This bit of code demonstrates:

#include <stdio.h>
int main() {
        printf("test: %s\n",NULL);
}

On Linux and FreeBSD, this prints out "test: (null)" but on Solaris 10 this
dumps core.

Fixing this is beyond my skill level.  But I would start looking at the
functions errprintf() and dbgprintf() to see if NULL strings can be
detected and prevented from being passed through to *printf.

But that might be somewhat tricky.  Alternatively, updating
dump_tcp_services() to do the same, is probably a much simpler task, but
doesn't safeguard any other code from the same fate.

J


On 11 March 2015 at 17:38, Jeremy Laidman <user-71895fb2e44c@xymon.invalid> wrote:
Even simpler:

#include <stdio.h>
int main() {
        printf("test: %s\n",NULL);
}


On 11 March 2015 at 17:33, Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
wrote:
On 11 March 2015 at 15:43, Vernon Everett <user-b3f8dacb72c8@xymon.invalid>
wrote:
We have 4.3.12
And the command dumps core in the same way.
That's good.

Can you try this out?  Plop into a text file, eg test.c, then "make test"
and then "./test".

#include <stdio.h>
#include <stdarg.h>
void dbgprintf(const char *fmt, ...)
{
        va_list args;
        va_start(args, fmt);
        vfprintf(stdout, fmt, args);
        va_end(args);
        fflush(stdout);
}
int main() {
        dbgprintf("test: %s\n",NULL);
}

This is the essence of the Xymon code that prints the empty send/expect
strings.  But I've pared away all of the Xymon code to leave just the call
to vprintf() and whatever is needed to make it run.

On my systems I get the following output:

test: (null)

I'm guessing on your system you'll get a core dump.  If so, it would
suggest a difference in implementations of the standard library functions.
If that's the case, we simply (!) need to catch the attempts to print NULL
pointers, and substitute our own "(null)" string.

Indeed, I just tested this on a Solaris system and it dumped core.  On
Linux and FreeBSD systems, it printed "(null)".

J