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


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

Submitted by:  Taylor R. Campbell <riastradh>
Submitted on:  Tue 03 Apr 2007 09:11:12 PM UTC  
Category: imailSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect behavior
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: Open

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


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>
Project Member


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

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by riastradh (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 09 Jul 2008 01:56:17 PM UTCriastradhAttached File#16074=>Removed
    Wed 09 Jul 2008 07:34:32 AM UTCNoneAttached File-=>Added powered_php_80x15_2.png, #16074

    Back to the top

    Powered by Savane 3.1-cleanup1