I have a daemon I'm working on that seems to bomb out in the middle of strcmp, WAY down in the bowels of the ODBC library. It would run for hours, then just mysteriously quit (well, as mysteriously as a SIGSEGV can be)- classic memory corruption symptom. So, I built it with Electric Fence (which, at least superficially, seems a pretty nifty product). When I start it with gdb, this is what I get, pretty much immediately, as the program is initializing:
Note the shared libraries
#0 0xa7996270 in strcmp () from /lib/tls/libc.so.6
#1 0xa794a0d9 in setlocale () from /lib/tls/libc.so.6
#2 0xa60c43fa in my_SQLExtendedFetch () from /usr/lib/odbc/libmyodbc.so
#3 0xa60c45b6 in SQLFetch () from /usr/lib/odbc/libmyodbc.so
#4 0xa7a7d798 in SQLFetch () from /usr/lib/libodbc.so.1
#5 0x0805604b in t_dbBuffer<topic>::GetNext (this=0xa6a8cfd8,
#6 0x08050844 in rssd::InitRSS (this=0xa6d4cf1c) at rssd.cpp:808
#7 0x08050997 in rssd::AppInit (this=0xa6d4cf1c) at rssd.cpp:667
#8 0x0805c9b6 in main (argc=1, argv=0xafe3e6a4) at App.cpp:47
I've got at least two questions here: I wrote my own quick and dirty strcmp to at least try and find out what the comparison strings were, but, although all the code I wrote picks up my strcmp, this part of the code doesn't.
Why would it use two different copies of strcmp?
How do I force it to use my version?
Here's the compile line, with all make substitutions done:
gcc rssd.cpp topic.o user.o subscription.o smsClt.o -o rssd -g -D_LINUX -I ~anw/Software/Headers -I /usr/include/nptl -L /usr/lib/debug -L~anw/Software/Libraries -L /usr/lib/nptl -D _LINUX -DNETDATASVC_EXPORTS -lApp -lLog -lxml -lxerces-c -lstdc++ -lpthread -lSimpleNet -lSerPort -lodbc -lDBUtils -lefence
rm topic.o subscription.o user.o smsClt.o
My strcmp is in the library ~anw/Software/Libraries/libDBUtils.a.
Note, also, that I have the debug versions of the standard libraries installed (the -L /usr/lib/debug switch), and, evidently, it's not picking up those either.