Tue Jan 24 23:56:36 HKT 2012 From /weblog/languages/c
memory issue
Personal memo about C++ memory management, from a Java developer, contain some rule of thumb tips - http://karussell.wordpress.com[..]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[..]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[..]-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=
pMsg=0x6b0b14 "main. Database=XXXXXX. Performing Login to XXXX. user=SYSTEM.", nFile=0) at Util.cpp:164
#8 0x164e28 in _ZN7LogBook9PromptLogEPciS0_i (this=
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.
(google search) (amazon search)