[Box Backup] Debugging boxbackup

[Ben Lovett]

On Wed, Jan 28, 2004 at 10:47:14PM +0000, Ben Summers wrote:
> 
> On 28 Jan 2004, at 22:36, Ben Lovett wrote:

<snip>

> >Core was generated by `bbstoreaccounts'.
> >Program terminated with signal 6, Aborted.
> >#0  0x0000000048ab6800 in ?? ()
> >(gdb) bt
> >#0  0x0000000048ab6800 in ?? ()
> >#1  0x00000000001360e4 in Configuration::LoadAndVerify(char const*, 
> >ConfigurationVerify const*, std::string&) (Filename=0x0, pVerify=0x0, 
> >rErrorMsg=@0x0)
> >    at Configuration.cpp:144
> >#2  0x0000000000136474 in Configuration::LoadAndVerify(char const*, 
> >ConfigurationVerify const*, std::string&) (Filename=0x0, pVerify=0x0, 
> >rErrorMsg=@0x0)
> >    at Configuration.cpp:179
> 
> That's a bit odd, it shouldn't have all zeros as parameters -- possibly 
> it's not correct as it sounds as if you're using something from one 
> build with another. You certainly wouldn't see it getting far enough to 
> recurse if it were the case.
> 
> If you build the and run the debug version of bbstoreaccounts under gdb 
> with
> 
>   cd bin/bbstoreaccounts
>   make
>   cd ../../debug/bin/bbstoreaccounts
>   gdb bbstoreaccounts
> 
> then in gdb, type
> 
>   run -c <configfilename> create 21
> 
> for example (with <configfilename> replaced with the config file you're 
> using). It should then crash, then type
> 
>   bt
> 
> to see the backtrace, and it should be more accurate.

ok ..

with gdb 4.16.1 i get --

(gdb) run -c /etc/ports/box/bbstored.conf create 21
Starting program: /usr/home/ben/boxbackup-0.03/debug/bin/bbstoreaccounts/bbstoreaccounts -c /etc/ports/box/bbstored.conf create 21

Program received signal SIGSEGV, Segmentation fault.
0x16bc48 in _ZNSt8_Rb_treeIPvSt4pairIKS0_15MallocBlockInfoESt10_Select1stIS4_ESt4lessIS0_ESaIS4_EE11lower_boundERS2_ (this=0x90ffffffffffffdf, 
    __k=@0xe0ffffffffffff39) at MemLeakFinder.cpp:108
108     }
(gdb) bt
#0  0x16bc48 in _ZNSt8_Rb_treeIPvSt4pairIKS0_15MallocBlockInfoESt10_Select1stIS4_ESt4lessIS0_ESaIS4_EE11lower_boundERS2_ (this=0x90ffffffffffffdf, 
    __k=@0xe0ffffffffffff39) at MemLeakFinder.cpp:108
#1  0x16bba4 in _ZNSt3mapIPv15MallocBlockInfoSt4lessIS0_ESaISt4pairIKS0_S1_EEE11lower_boundERS5_ (this=<incomplete type>, __x=@0x1cffffffffffff43)
    at MemLeakFinder.cpp:108
#2  0x16ba28 in _ZNSt3mapIPv15MallocBlockInfoSt4lessIS0_ESaISt4pairIKS0_S1_EEEixERS5_ (this=<incomplete type>, __k=@0x0) at MemLeakFinder.cpp:108
#3  0x14b9cc in memleakfinder_malloc (size=0, file=0x0, line=0)
    at MemLeakFinder.cpp:98
#4  0x15b1bc in _ZN16MemoryBlockGuardIPhEC1Ei (this=<incomplete type>, 
    BlockSize=0) at BackupStoreFilenameClear.cpp:75
#5  0x119d98 in _Z41__static_initialization_and_destruction_0ii (
    __initialize_p=0, __priority=0) at BackupStoreFilenameClear.cpp:75
#6  0x119ebc in _GLOBAL__I__ZN45_GLOBAL__N_BackupStoreFilenameClear.cpp1PX2Zs13sEncodeMethodE () at BackupStoreFilenameClear.cpp:75
#7  0x104188 in ___start ()
#8  0x1041d8 in ___start ()
#9  0x103f0c in __init ()
#10 0x10403c in ___start ()

that looks _really_ weird..

i'm not 100% sure that everything is fine with this systems install of gcc3,
but i'm reasonably sure since i have not had any other problems.. maybe i'll
try doing a reinstall if the current snapshots have gcc3 in them.

the backtrace where you thought that it was maybe gcc 2.95.x STL, with gcc3
was captured using gdb 6, which has much better sparc64 support, so i was
trusting it more in the beginning.

thanks,

--ben