Re: [Monotone-devel] mtn uninterruptible

[Thomas Moschny]

On Wednesday 19 July 2006 09:57 Nathaniel Smith wrote:
> I found that my optimized build did this on every try, while my
> unoptimized build almost always just exited immediately (i.e., behaved
> correctly).  After trying enough times, I did manage to get it to
> freeze, and attached gdb.  Here's the complete stack trace:
>
> #0  0xb7d2d189 in __lll_mutex_lock_wait () from /lib/tls/libc.so.6
> #1  0xb7cb9915 in _L_mutex_lock_2729 () from /lib/tls/libc.so.6
> #2  0xb6800600 in ?? ()
> #3  0x00000002 in ?? ()
> #4  0x00000000 in ?? ()

Hmm, here's what I got:

#0  0x0081f402 in __kernel_vsyscall () at ./botan/pk_core.h:32
#1  0x00978e3e in __lll_mutex_lock_wait () at ./botan/pk_core.h:32
#2  0x0090bdf8 in _L_lock_13946 () at ./botan/pk_core.h:32
#3  0x0090b3e3 in free () at ./botan/pk_core.h:32
#4  0x00c766c1 in operator delete () at ./botan/pk_core.h:32
#5  0x08161cbd in std::_Rb_tree<sqlite3*, sqlite3*, std::_Identity<sqlite3*>, 
std::less<sqlite3*>, std::allocator<sqlite3*> >::_M_erase (this=0x84c4f80, 
__x=0x95e2688)
    at 
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/ext/new_allocator.h:94
#6  0x08141272 in close_all_databases ()
    at 
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_tree.h:692
#7  0x0828bddd in main_with_signal_handlers (argc=2, argv=0xbfac3f64) at 
main.cc:349
#8  0x0828c03a in main (argc=Cannot access memory at address 0x0) at main.cc:375

- Thomas

-- 
Ninety percent of the time things turn out worse than you thought they would.
The other ten percent of the time you had no right to expect that much.
                -- Augustine