:) hello Andy! Thank you for the quick response. I killed off the offending
processes, but I fould some new ones. They're not quite as large users of
memory, but they've stayed on for some time. Here's the gdb output from one
of them (This is my first venture in gdb land, so please tell me if I did
something wrong):

#> gdb /var/qmail/bincimap/bin/bincimapd 31418
GNU gdb 4.16.1
Copyright 1996 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 "i386-unknown-openbsd3.3"...

/proc/31418/31418: No such file or directory.
Attaching to program `/var/qmail/bincimap/bin/bincimapd', process 31418
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /usr/lib/libstdc++.so.31.0...done.
Reading symbols from /usr/lib/libm.so.1.0...done.
Reading symbols from /usr/lib/libc.so.29.0...done.
0x40247e85 in memcpy ()
(gdb) bt
#0  0x40247e85 in memcpy ()
#1  0x223000 in ?? ()
#2  0x401a99bd in __overflow ()
#3  0x401a9e1d in _IO_default_xsputn ()
#4  0x401a3b98 in streambuf::xsputn ()
#5  0x401a1ec3 in ostream::write ()
#6  0x733be in
__ls__H3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_R7ostre
amRCt12basic_string3ZX01ZX11ZX21_R7ostream ([EMAIL PROTECTED], [EMAIL PROTECTED]) at
/usr/include/g++/std/bastring.cc:470
#7  0x735a4 in
__ls__H1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_temp
late2b0i0_Q24Binc2IORCX01_RQ24Binc2IO (
    this=0x184000, [EMAIL PROTECTED]) at convert.h:295
#8  0x71419 in Binc::MaildirMessage::printBody (this=0x19c05c) at
maildirmessage.cc:848
#9  0xec0d2 in Binc::FetchOperator::process (this=Error accessing memory
address 0x0: Invalid argument.
) at operator-fetch.cc:280
#10 0x16580 in main (argc=1, argv=0xcfbfd208) at bincimapd.cc:147

There is no fd under /proc/31418/, so can't list what files it uses. :-/ But
I assume line #9 is the offender?

Regards,

Lasse Danielsen

-----Original Message-----

I guess they all come from the same large mailbox. In 1.2.0b1, the method
for reading data from a message and converting to CRLF changed. It might
well be that there is a problem with this.

Could you attach to one of the hanging bincimapd processes with gdb for
me?

gdb <path> <pid>

Then do a backtrace with "bt" and paste the output to the list.

Note that if the gdb backtrace doesn't contain line numbers, you would
have to compile bincimapd with debug info/not strip the binaries.

It's also interesting to know what files the processes have open - under
/proc/<pid>/fd you will find a list. You could copy the involved files
into a test Maildir folder and see if you can reproduce the problem there.

I'm sure we can find the bug quite fast, since the diff between 1.1.9 and
1.2.0b1 isn't very big. :-)

Andy

--
Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP    | "It is better not to do something
                       |  than to do it poorly."


Reply via email to