[Thanks for your quick reply yesterday David!]
So, resurrecting a 4-year-old thread here.. I'm getting "Too many open
files" errors running mhfixmsg on folders of over around 1020 messages,
congruent to my descriptors limit of 1024.
David, you earlier (like, January 2016 earlier) said you couldn't
replicate this with valgrind, but when I run
valgrind --leak-check=full --track-fds=yes uip/mhfixmsg -verbose +z all
from the latest git sources off Savannah, I find all the leaked
descriptors to come from mhfixmsgsbr:
==27025== Open file descriptor 5: /home/conrad/.Mail/mhfixmsgrSu5Zs
==27025== at 0x4B861AE: open (open64.c:48)
==27025== by 0x4B095C2: __gen_tempname (tempname.c:261)
==27025== by 0x129DB9: m_mktemp (m_mktemp.c:64)
==27025== by 0x10EF61: mhfixmsgsbr (mhfixmsg.c:604)
==27025== by 0x10EF61: main (mhfixmsg.c:541)
It *looks* to me as if the declaration in mhfixmsgsbr() that outfp will
be closed by its caller is not strictly true: if I understand correctly,
a new file is opened every time the cts/ctp loop on line 540 iterates,
where the only *close* is a singular one on line 564. Adding a line 554
along the lines of
if (outfp) { fclose (outfp); outfp = NULL; }
.. appears to solve things for me without breaking any tests; I'm unsure
whether line 564 needs to remain for other code paths though. Seems
*possible* there was a no-longer-relevant design decision to relinquish
control over outfp, and it could perhaps now be closed in mhfixmsgsbr()?
Conrad