Oort gnus oddities....

Oort gnus oddities....

[Jesse F. Hughes]

Hey ho.

Since updating recently to Oort, I have consistently gotten errors
when reading from my IMAP box.  I've mentioned some of these
previously, but I confess I haven't done much to investigate the
errors yet.  Now, I think, it's time to do so, since they're starting
to get under my skin.

Note: Maybe the errors are on the server side, but I'm hopeful we have
a workaround.  In any case, Gnus is crashing my XEmacs entirely on
occasion, and that can't be the server's fault.

Here's the information I have.  Please let me know if anything's
missing.

"Oort Gnus v0.06"

XEmacs 21.1 (patch 14) "Cuyahoga Valley" [Lucid]
(i386-slackware-linux, Mule) of Wed Apr 11 2001 on grunt

When I hit "g" (or "1 g") in the *Group* buffer, I sometimes (often)
see the following.

(1) (error/warning) Error in process filter: (error Internal error,
tag 145 status BAD code nil text Server in unknown state for SELECT
command)

Here's the *imap-log* entry around that time.

* BYE Autologout; idle for too long
145 SELECT "INBOX"
145 BAD Server in unknown state for SELECT command
146 STATUS "INBOX/KUN/employment" (uidnext)
147 STATUS "INBOX/JournalsAndConferences" (uidnext)
148 STATUS "mail.jobs" (uidnext)
149 STATUS "mail.KUN.employment" (uidnext)
150 STATUS "mail.Journals.and.Conferences" (uidnext)
151 STATUS "mail.CCSL" (uidnext)
152 STATUS "mail.lists.admin" (uidnext)
153 STATUS "INBOX" (uidnext)
154 STATUS "mail.lists.tulip" (uidnext)
155 STATUS "mail.lists.fom" (uidnext)
156 STATUS "mail.lists.livid" (uidnext)
157 STATUS "mail.lists.airlines" (uidnext)
158 STATUS "mail.cron" (uidnext)
159 STATUS "mail.lists.categories" (uidnext)
160 STATUS "mail.trash" (uidnext)
161 STATUS "mail.ITT" (uidnext)
162 STATUS "mail.lists.coalgebras" (uidnext)
163 STATUS "mail.lists.redhat" (uidnext)
164 STATUS "mail.lists.commercial" (uidnext)
165 STATUS "mail.lists.alsa" (uidnext)
166 STATUS "INBOX/ITT" (uidnext)
167 STATUS "INBOX/lists/airlines" (uidnext)
168 STATUS "INBOX/lists/categories" (uidnext)
169 STATUS "INBOX/lists/commercial" (uidnext)
170 STATUS "INBOX/lists/tulip" (uidnext)
171 STATUS "INBOX/trash" (uidnext)
172 STATUS "INBOX/CCSL" (uidnext)
read:errno=0

Here is the message log from the same period.

Internal error: lstream not open: #<INTERNAL EMACS BUG (filedesc lstream) 0x0x8871330>
Internal error: lstream not open: #<INTERNAL EMACS BUG (filedesc lstream) 0x0x8871330>
nnimap: Checking mailbox INBOX/CCSL
nnimap: Checking mailbox INBOX/trash
nnimap: Checking mailbox INBOX/lists/tulip
nnimap: Checking mailbox INBOX/lists/commercial
nnimap: Checking mailbox INBOX/lists/categories
nnimap: Checking mailbox INBOX/lists/airlines
nnimap: Checking mailbox INBOX/ITT
nnimap: Checking mailbox mail.lists.alsa
nnimap: Checking mailbox mail.lists.commercial
nnimap: Checking mailbox mail.lists.redhat
nnimap: Checking mailbox mail.lists.coalgebras
nnimap: Checking mailbox mail.ITT
nnimap: Checking mailbox mail.trash
nnimap: Checking mailbox mail.lists.categories
nnimap: Checking mailbox mail.cron
nnimap: Checking mailbox mail.lists.airlines
nnimap: Checking mailbox mail.lists.livid
nnimap: Checking mailbox mail.lists.fom
nnimap: Checking mailbox mail.lists.tulip
nnimap: Checking mailbox INBOX
nnimap: Checking mailbox mail.lists.admin
nnimap: Checking mailbox mail.CCSL
nnimap: Checking mailbox mail.Journals.and.Conferences
nnimap: Checking mailbox mail.KUN.employment
nnimap: Checking mailbox mail.jobs
nnimap: Checking mailbox INBOX/JournalsAndConferences
nnimap: Checking mailbox INBOX/KUN/employment
nnimap: Checking mailboxes...

Now, usually, if I hit "g" again, then it re-opens the connection and
continues happily.  Sometimes, however, my xemacs crashes entirely.
I'd be happy to gather some data from one of those times, if it's
useful, but I don't have the know-how.

Thanks for any help you can offer.

-- 
"After all, you remain ignorant no matter what I say anyway, so maybe I
should just quit torturing you (and myself) with information that is
so clearly beyond the limits of your cognitive processes."
  --James Harris IV: A New Hope

Re: Oort gnus oddities....

[Simon Josefsson]

jesseh@cs.kun.nl (Jesse F. Hughes) writes:

> When I hit "g" (or "1 g") in the *Group* buffer, I sometimes (often)
> see the following.
>
> (1) (error/warning) Error in process filter: (error Internal error,
> tag 145 status BAD code nil text Server in unknown state for SELECT
> command)
>
> Here's the *imap-log* entry around that time.
>
> * BYE Autologout; idle for too long
> 145 SELECT "INBOX"
> 145 BAD Server in unknown state for SELECT command

This was reported earlier, and seemed like a server bug.  Could you
show some more output from the *imap-log* buffer?  In particular, the
previous commands sent to that server before command 145.

Which server is this?

Re: Oort gnus oddities....

[Simon Josefsson]

jesseh@cs.kun.nl (Jesse F. Hughes) writes:

>> This was reported earlier, and seemed like a server bug.  Could you
>> show some more output from the *imap-log* buffer?  In particular, the
>> previous commands sent to that server before command 145.
>
> I'll do that just as soon as I see it again.

Thanks.

> Even if it is a server bug, I'm surprised to see Gnus take down my
> xemacs.  I reckon that there's a somewhat rare condition triggered by
> these events that's doing the dirty deed.

Have you reported it?  Gnus can't prevent XEmacs from crashing.

>> Which server is this?
>
> In the earlier incident, we had this exchange.
>
>     > * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS AUTH=PLAIN
>     > AUTH=LOGIN] ***.***.kun.nl IMAP4rev1 2001.310 at Wed, 31 Jul
>     > 2002 22:18:57 +0200 (MET DST)
>
>     That looks like the UoW 2000 server, I'll forward as it is
>     supposed to be the reference implementation.  Thanks.

Ah, I remember now. :-)

Yes, I reported it, and there were some discussion about the other
problem, but the one you mentioned here now was a bug.  Without more
information on what is earlier in the *imap-log* it is difficult to
work around the problem.  It looks as if the server didn't let you
into the INBOX, and also returned a BAD which indicates a protocol
error in the client.