> Lots of info can be gained quickly with a simple stacktrace,
> instructions for which shouldn't be hard to dig out of even the most
> voluminous documentation.
>
> I'd suggest post mortem examination of the core first; you don't have
> to worry about changing conditions with your debugging attempts that way.
>
> ]- aren't comfortable with a debugger, place output statements throughout
> ]- your code to try to figure out where it is crashing
>
> Whether you add diagnostics or use a debugger be aware that your
> actions might change critical timings in reproducing the problem.
> Probably not in this case but it's hard to tell with the info you
> gave. My general preference is to do as little as possible to capture
> the minimum amount of information which might be used correctly
> identify the root cause.
Good point.
> ]- (be certain to use fprintf(stderr, not printf since printf is
> ]- buffered output.
>
> This is the only point I'd disagree with. I think you'll find that
> both named routines are buffered, or that the stream passed to fprintf
> is irrelevant. Certainly it used to be that stdio was all buffered
> until a newline was output or the stream's buffer was full. Even then
> you can force the issue with fflush() and most involutary process
> exits flush stdio streams.
I did leave off one important point. I believe fprintf is buffered
until a new line so make certain you do fprintf(stderr, "....\n");
This does not work with printf even new lines are not guaranteed to
flush the buffer. Of course fflush(stdout) will do the trick.
Dave
[EMAIL PROTECTED]
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
