[an error occurred while processing this directive]
Node:Profiled crash,
Next:Garbled profile,
Previous:How to profile,
Up:Profiling
Q: I cannot profile my program: when I compile it with -pg, it
crashes or wedges my machine!
Q: When I compile my program with -pg, it runs much slower. Does
the profiling code have such a huge overhead?
Q: I profiled my program, but the profile contains an entry
_mono_putc
which I don't use, and which eats up about 70% of
execution time!
Q: When I run a profiled program on my dual (VGA+MDA) display
system, the mono screen shows loads of meaningless numbers. Is there a
way to stop this behavior?
A: DJGPP v2.01 has a bug in one of its library functions which is
linked into your program when it is compiled with the -pg
option.
The bug is that the profiled program tries to write to the secondary
mono screen, which caused the profiled programs to crash in many
environments, in particular when a memory manager remaps some of the
high memory. On systems which actually have the additional mono
display, the profiled programs won't crash, but would run significantly
slower and print debugging info on the mono display.
A patch which corrects this bug was posted to the DJGPP News group; you
can find it by searching the DJGPP mail archives. DJGPP v2.02 and later
includes a fixed version of the offending function, so upgrade to the
latest version. A work-around is to run the program compiled with
-pg
on vanilla DOS configuration (no memory managers such as
EMM386 or QEMM, and no Windows). However, when you use this
work-around, your program might run much slower, although the profile
that you get should not be affected.