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

 
 

bug #37968: mhpath triggers glibc memory guard

Submitted by:  Theodore Phelps <phelps>
Submitted on:  Fri 21 Dec 2012 03:08:07 AM UTC  
 
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalStatus: Fixed
Assigned to: NoneOpen/Closed: Closed

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

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>
Project 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>
Project 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 File(s):
   
   
Comment:
   

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

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

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 07 Jan 2013 10:46:14 PM UTCkenhStatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Fri 21 Dec 2012 03:36:51 AM UTCkenhStatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup