bugGNUstep Non-FSF - Bugs: bug #55222, [Pantomime] Default timeout too...


bug #55222: [Pantomime] Default timeout too small and makes connection impossible

Submitter:  Yavor Doganov <yavor>
Submitted:  Thu 13 Dec 2018 08:50:18 PM UTC
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Tue 27 Sep 2022 11:45:40 AM UTC, comment #1: 

I think we have perhaps two issues, one is timeout, one is bad handling of it, or maybe together.

I get a timeout sometimes with my ISP IMAP provider where Mozilla does not, even with folders which are not particularly heavy.

Could you try putting a breakpoint in the place and get a stacktrace?

Riccardo Mottola <rmottola>
Group administrator
Thu 13 Dec 2018 08:50:18 PM UTC, original submission:  

Pantomime & GNUMail 1.3.0

It appears that GNUMail is the only MUA in Debian that cannot connect reliably to my IMAP server.  In most cases a dialog is displayed that the connection timed out.  Sometimes (rarely) it connects but if I switch to another folder it throws me out quickly.  The server is a Pentium III box with 256 MB RAM, running Dovecot/2.2.27 on Debian GNU/Linux (stretch).  I am attempting connections from another (more powerful) machine on the local network.  Worth mentioning that my inbox has ~50K messages.

All other MUAs I've tried (Wanderlust, Gnus, Mutt, Evolution, Balsa, Claws Mail, plus some more obscure ones) connect flawlessly even though I have to wait for a few minutes.  Waiting is perfectly acceptable for me given the above constraints, cutting me out is not.  Increasing the timeout as in the attached patch fixes the problem, although GNUMail's UI freezes for long periods when switching accounts and/or folders.  Often the UI freeze is accompanied with heavy load (on the client machine) and lots of repeated output on the console, like:

read_unsinged_int: EOF
2018-12-13 21:57:21.028 GNUMail[30636:30636] stringWithData - iconv fallback, charset: cp1251

AFAIU this is when reading the cache and is not related to the connection and the timeout issue.

I'm not sure as I'm not familiar with the relevant RFCs, but I think that there should be no timeout -- the client should continue attempting connection until the server timeouts or until the user cancels the operation.  At least this is the behavior with all the other MUAs I've tried.

Yavor Doganov <yavor>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #45647:  increase-timeout.patch added by yavor (499B - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by yavor (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-13 yavor Attached File- Added increase-timeout.patch, #45647

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code