log4c : use it everywhere

[GoogleCodeExporter]

Project page:
* http://log4c.sourceforge.net/

More links
* http://stackoverflow.com/questions/tagged/log4c
* http://logging.apache.org/log4net/release/manual/configuration.html ( 
configuration on the library is sparce, use the log4net to se if similarities )
* http://cdn.bitbucket.org/bearsh/log4c/downloads/Log4C-DevelopersGuide.pdf - 
Log4C Developers guide, PDF. Attached.

Original issue reported on code.google.com by geo...@marsel.is on 19 May 2013 at 11:00

Attachments:

• Log4C-DevelopersGuide.pdf

[GoogleCodeExporter]

* 
logging messages is relatively expensive­­so 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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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 
stack­­in 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 HP­UX, 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

[GoogleCodeExporter]

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

• Added labels: Performance

[GoogleCodeExporter]

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