On Fri, 17 Dec 2004, Andreas Aardal Hanssen wrote:
Sorry about this, Jorge. You did it all right, but I forgot one thing. After attaching, at the (gdb) prompt, first do "cont". Then reproduce the error with the IMAP connection.
OK, here it goes:
$ gdb /usr/bin/bincimapd 4693 GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1".
Attaching to program: /usr/bin/bincimapd, process 4693 Reading symbols from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 0x401dd132 in select () from /lib/libc.so.6 (gdb) cont Continuing.
Program received signal SIGABRT, Aborted.
0x40155f21 in kill () from /lib/libc.so.6
(gdb) bt
#0 0x40155f21 in kill () from /lib/libc.so.6
#1 0x40155b45 in raise () from /lib/libc.so.6
#2 0x4015730d in abort () from /lib/libc.so.6
#3 0x400d877f in __cxa_call_unexpected () from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5
#4 0x400d87b4 in std::terminate() () from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5
#5 0x400d8954 in __cxa_throw () from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5
#6 0x400d8bcd in operator new(unsigned) () from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5
#7 0x400c393f in std::__default_alloc_template<true,
0>::_Lock::~_Lock() ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5
#8 0x400c3697 in std::__default_alloc_template<true,
0>::_S_chunk_alloc(unsigned, int&) ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5
#9 0x400c34e3 in std::__default_alloc_template<true,
0>::_S_refill(unsigned) ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5
#10 0x400c31df in std::__default_alloc_template<true,
0>::allocate(unsigned) ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5
#11 0x08075d08 in std::basic_string<char,
std::char_traits<char>, std::allocator<char> >
std::operator+<char, std::char_trait---Type <return> to
continue, or q <return> to quit---
s<char>, std::allocator<char> >(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) ()
#12 0x0000003c in ?? ()
#13 0x080d44dc in std::string::_S_empty_rep_storage ()
#14 0xbfffee60 in ?? ()
#15 0xbffff040 in ?? ()
#16 0xbffff010 in ?? ()
#17 0xbffff0c0 in ?? ()
#18 0xbffff014 in ?? ()
#19 0x08075c36 in std::basic_string<char,
std::char_traits<char>, std::allocator<char> >
std::operator+<char, std::char_traits<char>,
std::allocator<char> >(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) ()
#20 0xbffff040 in ?? ()
#21 0xbffff0c0 in ?? ()
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or
n) n
Not confirmed.
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or
n) n
Not confirmed.
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or
n) y
Detaching from program: /usr/bin/bincimapd, process 4693
~This time, I had to kill the session with Ctrl-C, it was just hanging there.
Just a thought: mail is delivered to different mailboxes via procmail. Since I thought that no locking was needed with maildirs, I didn't put the locking ':' at the first line of procmail recipes. Could this be the problem? It might explain why it only happens with some lists--the high volume ones.
Jorge
