Open GoogleCodeExporter opened 9 years ago
*
logging messages is relatively expensiveso once you turn on, especi
ally heavy logging, then
your code spends a lot of it time in there.
It would be interesting to run a collector/analyzer to
quantify that.
So, in the case where there is general memory corruption in your s
ystem it is
quite likely that when it does crash, it will be in your logging co
de. This accounts for 2 of the 4
bugs I mention that crashed Log4C
Original comment by geo...@marsel.is
on 19 May 2013 at 11:01
USE ASSERTIONS!
*
Often folks will put debug log statements (good!) without ever testing
them (bad!). So some
errors of the form of a mismatch between the format string and the
parameter list can easily
arise.
These bugs at least have the merit of being easy to spot once the
y do occur. That was
one of the 4 bugs.
Original comment by geo...@marsel.is
on 19 May 2013 at 11:01
watch out if your stack size is small:
especially if you are on a 64 bit system (where you double the memo
ry consumed by pointer types)
*
Enabling logging calls obviously triggers an extra depth in the call
stackin the case of Log4C
using the stream appender this can be up to 10 deep by the time yo
u hit the base write() call to
write to the file.
So watch out if your stack size is small, especially if you are o
n a 64 bit
system (where you double the memory consumed by pointer types) and es
pecially if your code
is already stack hungry.
This of course describes exactly the scenario of the 4th bug that
crashed Log4C. For information, on HPUX, where we saw this problem
, the default stack
size for threads is 64K, which is pretty small compared with defaults
of 1M on Solaris and
Windows and 2M on Linux
Original comment by geo...@marsel.is
on 19 May 2013 at 11:03
watch the size of the stack, when logging is turned on, throw out warnings if
getting small
google "figure out size of stack" :
http://stackoverflow.com/questions/53827/checking-available-stack-size-in-c
Although if you've ever tried to write really, truly portable code, you learn
that "you always have to ask, and you're always doing something wrong, because
there is no portable concept of "stack usage" and yet it's the programmer's
responsibility not to use too much stack. So it's best just to join the
conspiracy of silence, write a functional test that you hope consumes as much
stack as your program ever will in practice, and leave it to the platform
integrator to worry about"
http://stackoverflow.com/questions/1678803/how-to-determine-stack-size-of-a-prog
ram-in-linux
Original comment by geo...@marsel.is
on 19 May 2013 at 11:06
can i figure out how deep in the stack i am, so i can indent the debugging
output?
alternatively just print the current function name and offer a configurable
option/verbosity to just print the stack call.
make it user configurable
Original comment by geo...@marsel.is
on 19 May 2013 at 11:37
Original issue reported on code.google.com by
geo...@marsel.is
on 19 May 2013 at 11:00Attachments: