Problem of malloc, and introduction to some improved version - http://betathoughts.blogspot.com/2010/02/history-of-malloc.html

Personal memo about C++ memory management, from a Java developer, contain some rule of thumb tips - http://karussell.wordpress.com/2012/01/19/java-guy-reboots-with-c-trying-to-understand-memory-mangement/

Tutorial of valgrind - http://www.thegeekstuff.com/2011/11/valgrind-memcheck/

Disucssion of GC in C++ - http://herbsutter.com/2011/10/25/garbage-collection-synopsis-and-c/

Core dump with few variable declaration removed - http://techblog.rosedu.org/c-extern-internals.html

Tracking memory allocation - http://jfdube.wordpress.com/2011/10/06/memory-management-part-2-allocations-tracking/

We have a process running fine for several years and recently have core dump everytime starting it up. here is the stacktrace:

(gdb) backtrace
#0  0xfe34251c in realfree () from /lib/libc.so.1
#1  0xfe342e28 in cleanfree () from /lib/libc.so.1
#2  0xfe341f5c in _malloc_unlocked () from /lib/libc.so.1
#3  0xfe341e50 in malloc () from /lib/libc.so.1
#4  0xfe38f534 in _findbuf () from /lib/libc.so.1
#5  0xfe384f38 in _doprnt () from /lib/libc.so.1
#6  0xfe3886fc in fprintf () from /lib/libc.so.1
#7  0x164f64 in _ZN7LogBook8WriteLogEPcS0_i (this=<incomplete type>, pType=0x5c00e8 "INFO",
    pMsg=0x6b0b14 "main. Database=XXXXXX. Performing Login to XXXX. user=SYSTEM.", nFile=0) at Util.cpp:164
#8  0x164e28 in _ZN7LogBook9PromptLogEPciS0_i (this=<incomplete type>, pType=0x5c00e8 "INFO",
    nType=3, pMsg=0x0, nFile=0) at Util.cpp:136
#9  0x14a364 in main (argc=3, argv=0xffbef5bc) at XXXX.cpp:385
(gdb)

Eventaully we found out the reason is the class LogBook is singleton, and it reuse few char* buffer internally, without delete and new in between, after adding delete and new for transaction, the process run correctly, as a rule of thumb, singleton is evil for most of the cases.