"Emerson, Tom # El Monte" wrote:
>
> Funny you should mention that -- right as I was reading this message,
> someone came up to me with a program that is dumping some output, then
> crashing -- the trouble is, the "output" shows it is in one part of the
> program, yet the stack trace shows it to be in another!!!  Seems there is
> some sort of screwy buffering going on with C/Posix programs.  I haven't
> duplicated this with a "simple, standalone program", but I have seen
> something like the following occur:
>
>    1) program starts up, displays a "program name & version" banner via
> standard C "printf" call [absolute first statement in main(argc,argv)]
>    1a) "debugging" printf's sprinkled throughout the code...
>    2) program opens a database, encounters an error, and calls DBEXPLAIN
> intrinsic
>    3) [optional] program flat out crashes [bounds violation/data memory
> trap/whatever]
>
> The OUTPUT, however, usually consists of one of either the DBEXPLAIN output
> ahead of the "program name & version" banner, or (if it crashed) the
> DBEXPLAIN & Stack trace from abort only, no "program name/version" banner at
> all!!!  Sometimes, however, the opening banner and "some of" (but not all)
> the debugging "printf's" will appear in the output before the stacktrace
> and/or DBEXPLAIN output, and, of course, absolutely nothing behind the stack
> trace...

The default POSIX C file stream I/O is buffered, and MPE I/O (DBEXPLAIN, etc)
is unbuffered.  Thus you get the weird output mixing.  People frequently
encounter this
when using Perl to do web CGIs that are calling MPE commands/programs.

The workaround is to do your POSIX I/O unbuffered.  Since the MPE I/O is
already unbuffered, your output will appear in the proper sequence.  You can
switch to unbuffered via setbuf()/setvbuf().

Or remain buffered, but do fflush() to flush your POSIX buffers before doing
any MPE I/O.

- Mark B.