Dave Reed's message says:
]- [ Snip a lot of good sense about other causes than glibc ]
Another common cause is slight differences in malloc/alignment
implementations, especially off by one's over page boundaries.
]- Use a debugger (e.g., gdb) to track down where it crashes or if you
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.
]- (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 think we'd agree though that if one relies on such diagnostic
messages one should be aware that they are generally buffered with all
that entails.
HTH
--
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.
