Gcc fails with "writing to process: bad address, imap"

Gcc fails with "writing to process: bad address, imap"

[Tassilo Horn]

Hi all,

Whenever I attach a big file (1MB) to a mail the gcc to the local imap
group fails issuing the message in the subject.  It's sent out by the
SMTP server, though.

And afterwards, the connection the the imap server is hosed.  It shows
up as open in the server buffer, but hitting RET on it will freeze
emacs.  I interrupted with C-g and tried to close the connection with C.
But that freezes emacs, too.  So the only think I can do is killing
emacs.  Quitting Gnus freezes Emacs, I guess because it tries to close
the broken connection...

The imap server is a locally running dovecot (1.1.4).  I have two
accounts on it.  Only the account which holds the gcc-ed group is
broken.  The other one works normally.

(add-to-list 'gnus-secondary-select-methods
	     '(nnimap "Fastmail"
		      (nnimap-address "localhost")
		      (nnimap-stream network)
		      (nnimap-authenticator login)))

(add-to-list 'gnus-secondary-select-methods
	     '(nnimap "Uni"
		      (nnimap-address "localhost")
		      (nnimap-stream network)
		      (nnimap-authenticator login)))

Below are the relevant debug messages.  In that case, the Uni accound is
the broken one.  Please tell me if you need more.  The problem is
absolutely reproducible.

Gnus v5.13
GNU Emacs 23.0.60.1 (x86_64-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2008-10-29 on thinkpad

That's what's in *Messages*.

--8<---------------cut here---------------start------------->8---
Sending...
The message size is too large, split? (y or n) 
Sending via mail...
220 deliver.uni-koblenz.de ESMTP Postfix
250-deliver.uni-koblenz.de
250-PIPELINING
250-SIZE 70000000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250 8BITMIME
250 Ok [2 times]
354 End data with <CR><LF>.<CR><LF>
250 Ok: queued as 095F6789A835
221 Bye
20081030T092829.578> nnimap: Updating info for nnimap+Uni:INBOX...
20081030T092829.701> nnimap: Updating info for nnimap+Uni:INBOX...done
ad-Orig-imap-send-command: writing to process: bad address, imap
--8<---------------cut here---------------end--------------->8---

That's what's in *nnimap-debug*:

--8<---------------cut here---------------start------------->8---
| 2 -> nnimap-possibly-change-group: group="INBOX" server="Uni"
| | 3 -> nnimap-possibly-change-server: server="Uni"
| | 3 <- nnimap-possibly-change-server: " *nnimap* Uni"
| 2 <- nnimap-possibly-change-group: "INBOX"
| 2 -> nnimap-before-find-minmax-bugworkaround: 
| 2 <- nnimap-before-find-minmax-bugworkaround: t
| 2 -> nnimap-find-minmax-uid: group="INBOX" examine=t
| 2 <- nnimap-find-minmax-uid: (594 1 872)
1 <- nnimap-request-group: t
======================================================================
1 -> nnimap-request-accept-article: group="INBOX" server="Uni" last=t
| 2 -> nnimap-possibly-change-server: server="Uni"
| 2 <- nnimap-possibly-change-server: " *nnimap* Uni"
--8<---------------cut here---------------end--------------->8---

And the same for *imag-debug*:

--8<---------------cut here---------------start------------->8---
| | 3 <- imap-message-map: (872 872)
| | 3 -> imap-mailbox-get: propname=exists mailbox=nil buffer=nil
| | 3 <- imap-mailbox-get: 594
| 2 -> imap-current-mailbox: buffer=" *nnimap* Uni"
| 2 <- imap-current-mailbox: "INBOX"
| 2 -> imap-mailbox-unselect: buffer=" *nnimap* Uni"
| | 3 -> imap-capability: identifier=UNSELECT buffer=nil
| | 3 <- imap-capability: (UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1 STARTTLS AUTH=PLAIN)
| | 3 -> imap-send-command-wait: command="UNSELECT" buffer=nil
| | | 4 -> imap-send-command: command="UNSELECT" buffer=nil
| | | | 5 -> imap-send-command-1: cmdstr="186 UNSELECT"
| | | | 5 <- imap-send-command-1: nil
| | | 4 <- imap-send-command: 186
| | | 4 -> imap-wait-for-tag: tag=186 buffer=nil
| | | | 5 -> imap-arrival-filter: proc=#<process imap> string="186 OK Unselect completed.
"
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: 29
| | | | | 6 -> imap-parse-response: 
| | | | | | 7 -> imap-parse-resp-text: 
| | | | | | | 8 -> imap-parse-resp-text-code: 
| | | | | | | 8 <- imap-parse-resp-text-code: nil
| | | | | | 7 <- imap-parse-resp-text: nil
| | | | | 6 <- imap-parse-response: nil
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: nil
| | | | 5 <- imap-arrival-filter: nil
| | | 4 <- imap-wait-for-tag: OK
| | 3 <- imap-send-command-wait: OK
| 2 <- imap-mailbox-unselect: t
| 2 -> imap-message-append: mailbox="INBOX" article=#<buffer  *acc*> flags=nil date-time=nil buffer=" *nnimap* Uni"
| | 3 -> imap-send-command-wait: command=("APPEND \"" "INBOX" "\" " #<buffer  *acc*>) buffer=nil
| | | 4 -> imap-send-command: command=("APPEND \"" "INBOX" "\" " #<buffer  *acc*>) buffer=nil
| | | | 5 -> imap-send-command-1: cmdstr="187 APPEND \"INBOX\" {2187179}"
| | | | 5 <- imap-send-command-1: nil
| | | | 5 -> imap-wait-for-tag: tag=187 buffer=nil
| | | | | 6 -> imap-arrival-filter: proc=#<process imap> string="+ OK
"
| | | | | | 7 -> imap-find-next-line: 
| | | | | | 7 <- imap-find-next-line: 7
| | | | | | 7 -> imap-parse-response: 
| | | | | | 7 <- imap-parse-response: "OK"
| | | | | | 7 -> imap-find-next-line: 
| | | | | | 7 <- imap-find-next-line: nil
| | | | | 6 <- imap-arrival-filter: nil
| | | | 5 <- imap-wait-for-tag: INCOMPLETE
--8<---------------cut here---------------end--------------->8---
-- 
Richard Stallman  doesn't use web  browsers. Emacs connects  directly to
the network driver and he reads and writes TCP/IP himself.

Re: Gcc fails with "writing to process: bad address, imap"

[Tassilo Horn]

Hi again,

when I've sent the big mail to produce the outputs I attached to my
previous mail, after killing emacs and restarting gnus, the mail
appeared in the gcc-ed group.  I think the output showes that, too.

> 20081030T092829.578> nnimap: Updating info for nnimap+Uni:INBOX...
> 20081030T092829.701> nnimap: Updating info for nnimap+Uni:INBOX...done
> ad-Orig-imap-send-command: writing to process: bad address, imap

Anyway, that's not the usual case and the connection to the account is
always broken after gcc-ing a big message.

Bye,
Tassilo

Re: Gcc fails with "writing to process: bad address, imap"

[Andreas Seltenreich]

Tassilo Horn writes:

>> ad-Orig-imap-send-command: writing to process: bad address, imap

Looks like there is an advice on imap-send-command.  Maybe it is the
culprit?

regards,
andreas

Re: Gcc fails with "writing to process: bad address, imap"

[Tassilo Horn]

Andreas Seltenreich <andreas+ding@gate450.dyndns.org> writes:

Hi Andreas,

>>> ad-Orig-imap-send-command: writing to process: bad address, imap
>
> Looks like there is an advice on imap-send-command.

Yes, there is:

,----[ C-h f imap-send-command RET ]
| imap-send-command is a compiled Lisp function in `imap.el'.
| 
| (imap-send-command command &optional buffer)
| 
| This function is advised.
| 
| Around-advice `trace-function '.
`----

When `nnimap-debug' is non-nil a whole set of functions will be traced.
See nnimap.el:1729.

> Maybe it is the culprit?

Hm, I don't think so.  It only generates some trace output...

Bye,
Tassilo

Re: Gcc fails with "writing to process: bad address, imap"

[Andreas Seltenreich]

Tassilo Horn writes:

> Andreas Seltenreich <andreas+ding@gate450.dyndns.org> writes:
>
>> Maybe it is the culprit?
>
> Hm, I don't think so.  It only generates some trace output...

I agree.  I didn't realize advising was part of nnimap's debug
mechanism...

regards,
andreas

Re: Gcc fails with "writing to process: bad address, imap"

[Tassilo Horn]

Andreas Seltenreich <andreas+ding@gate450.dyndns.org> writes:

Hi Andreas,

>>> Maybe it is the culprit?
>>
>> Hm, I don't think so.  It only generates some trace output...
>
> I agree.  I didn't realize advising was part of nnimap's debug
> mechanism...

I disabled *[nn]imap-debug* and restarted emacs just to be sure, and the
strange thing is that since then I have no problem with gcc-ing a group
when sending large messages.

Katsumi, I Cc-ed you, because I think you're the author of the debug
code.  Do you know why the trace-function advice triggers the bug I
described in my first message?

Bye,
Tassilo
-- 
A morning without coffee is like something without something else.

Re: Gcc fails with "writing to process: bad address, imap"

[Jason Riedy]

And Tassilo Horn writes:
> The imap server is a locally running dovecot (1.1.4).

I had the same problem a while back.  Switching to courier fixed
it at the cost of that annoying "INBOX." prefix.

Jason