You are not logged in

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.

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.

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.

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.