bugThe nmh Mail Handling System - Bugs: bug #37968, mhpath triggers glibc memory guard

 
 

bug #37968: mhpath triggers glibc memory guard

Submitter:  Theodore Phelps <phelps>
Submitted:  Fri 21 Dec 2012 03:08:07 AM UTC
   
 
Category:  Bug Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Fixed
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 07 Jan 2013 10:46:14 PM UTC, comment #4: 

Alright, I believe this is fixed as of commit e8840b3.

I think this bug has been around forever.  It can only be triggered when "cur" is too far outside of the folder limits (as you note, nmh allocates 100 extra folder slot entries) and the ALLOW_NEW flag is set, which is only set by "mhpath" and the draft folder code.  Fixing this wasn't hard, but it was delayed by the holidays and understanding the special handling that "cur" is subject to.

Ken Hornstein <kenh>
Group administrator
Fri 21 Dec 2012 04:15:07 AM UTC, comment #3: 

Yes, it only works if "cur" is way out of range.

I'm afraid I'm not entirely sure how I got there.  I was using mh-e and deleted a lot of messages via the +mhe-index/sequence/unseen folder.  When I tried to apply those deletes, my emacs hung until I hit C-g to kill it.  Further attempts to repopulate that folder would also hang.  I attached strace to emacs and noticed mhshow reporting the glibc error from the original submission.

So I wasn't playing games trying to break nmh, but mh-e might be doing some unusual stuff here to make the .../unseen folder dwim.

-Ted

Theodore Phelps <phelps>
Fri 21 Dec 2012 03:36:51 AM UTC, comment #2: 

Okay, I was able to reproduce this.  But ... this only works if your "cur" sequence is way out of range, right?  And you have to actually work to make that happen, as I see it.  Yes, it needs to be fixed, no doubt about it, I'm just trying to understand how you got there.

Ken Hornstein <kenh>
Group administrator
Fri 21 Dec 2012 03:11:54 AM UTC, comment #1: 

I should point out that this happens both with 1.5 and with current git (a5994609), and that I'm running on a Linux box with a 64-bit glibc-2.15.

-Ted

Theodore Phelps <phelps>
Fri 21 Dec 2012 03:08:07 AM UTC, original submission:  

I'm able to reliably trigger a memory access violation from mhpath:

    > mhpath +folder/name/changed cur
    /home/phelps/mail/folder/name/changed/135
    * glibc detected * mhpath: corrupted double-linked list: 0x000000000238e670 *

The folder in question has only two non-deleted entries: 27 and 28.  A little bit of debugging shows that folder_read() allocates 100 extra entries (for a total of 102), which would presumably avoid this problem in normal cases.  But 135 is too far past the last message and the set_select_empty() call at m_convert.c:184 is writing to random bits of memory.

I can try to put together a test case in the test suite if that would be useful.

Thanks,
-Ted

Theodore Phelps <phelps>

 

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

Attach Files:
   
   
Comment:
   

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 kenh (Posted a comment)
  • -email is unavailable- added by phelps (Submitted the item)
  •  

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-01-07 kenh StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2012-12-21 kenh StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code