bugMIT/GNU Scheme - Bugs: bug #19505, IMAIL silently fails when message...


bug #19505: IMAIL silently fails when message header fields exceed available memory

Submitter:  Taylor R. Campbell <riastradh>
Submitted:  Tue 03 Apr 2007 09:11:12 PM UTC
Category:  imail Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect behavior
Status:  None Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Tue 03 Apr 2007 09:11:12 PM UTC, original submission:  

In a sufficiently large folder (which is not very large -- the one I was trying this with has about fifteen hundred messages in it), when preloading the folder's outlines exhausts the available heap space, IMAIL silently fails, and sometimes disconnects from the server.  I'm not sure exactly where or when it is disconnecting from the server -- when I try to sort a folder, it doesn't disconnect, but when I try to summarize the folder, it does disconnect.  If IMAIL does not disconnect, the heap space remains nearly exhausted until I manually disconnect, which is sometimes impossible with the amount of space left.

Some possible ways to work around this come to mind:

1. Store each message header fields string in an external string until parsing it is requested, almost like file folders do, only with more overhead (one external string per message, rather than one per folder and an interval of it per message).
2. Add a secondary GC daemon to de-initialize message header fields, or store weak references to them.
3. Don't preload cached items; load those on demand.

The latter two require, which could operate conjointly, changing the method for PRELOAD-FOLDER-OUTLINES on IMAP folders to answer each FETCH response incrementally: currently all the responses are stored in-core collected in a list until control returns to PRELOAD-FOLDER-OUTLINES to process the list.

With the third option, it might be better to make the header fields be a stream, rather than a list, so that it would be unnecessary to parse the whole header every time the cached item is loaded.  On the other hand, the headers may not be large enough for this to matter much.

In the mean time, it would also be nice if IMAIL reported the heap exhaustion in some way, rather than silently failing and either disconnecting or possibly locking up Edwin.  The only way I can think now to implement this would be to create the editor cmdl with the console I/O port rather than a dummy I/O port, although I'm a little confused about how failure while generating a summary buffer manages to close the folder first.

Taylor R. Campbell <riastradh>
Group Member


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by riastradh (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.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-07-09 riastradh Attached File#16074 Removed
    2008-07-09 None Attached File- Added powered_php_80x15_2.png, #16074

    Back to the top

    Powered by Savane 3.13-ee12.
    Corresponding source code