On Thu, 2006-08-10 at 23:44 -0500, Jeremy C. Reed wrote:
There are many more "imap" processes without any network connection though.
These are the important processes then. What do ktrace and gdb backtraces show for them?
Okay, here is one that no longer has an network connection:
(gdb) bt full #0 0x2811d590 in ?? () No symbol table info available. #1 0x80a9230 in ?? () No symbol table info available. #2 0x80a8915 in ?? () No symbol table info available. #3 0x806104d in _fini () No symbol table info available. #4 0x8055ac9 in i_stream_create_file (fd=-1077937284, pool=0x0, max_buffer_size=3217030017, autoclose_fd=-1077937263) at istream-file.c:236 ..
Unfortunately this backtrace is completely corrupted..
Nothing for ktrace though. With ktracing enabled, next time doing gdb did add details (but maybe not related):
99399 imap PSIG SIGINT caught handler=0x80a92ec mask=0x0 code=0x0 99399 imap RET kevent -1 errno 4 Interrupted system call 99399 imap CALL write(0x6,0xbfbff7a3,0x1) 99399 imap GIO fd 6 wrote 1 byte "\^B" 99399 imap RET write 1 99399 imap CALL sigreturn(0xbfbff7c0) 99399 imap RET sigreturn JUSTRETURN 99399 imap CALL write(0x2,0x80cb1e0,0x2b) 99399 imap GIO fd 2 wrote 43 bytes "\^AFkevent() failed: Interrupted system call "
Hmm. This actually helps. It shows it's blocking in ioloop-notify-kqueue and it really shouldn't be blocking there. See if the attached patch helps.
I think I'll also do some other cleanups to kqueue code now that I finally really looked at it..