I have a primitive mp3 jukebox that runs 'mpg321 -o oss -z -@ big_honkin.m3u' everything puts along just fine (for over two days actually) before I get a message that there are no more filehandles available and it dumps out. In the process of looking at that, I discovered the joys of the remote mode which makes it even easier to find the problem. 'mpg321 -R -o oss dummy_param' and then 'load'ing a couple of songs results in the following lsof snippet: [reddirt@kiran reddirt]$ /usr/sbin/lsof | grep music sh 1137 reddirt 255r REG 3,2 49 32073 /home/reddirt/music_startup.sh mpg123 1138 reddirt 3r REG 3,9 7273485 2179082 /music/other/Suteki_da_ne_orchestral.mp3 mpg123 1138 reddirt 5r REG 3,9 9556953 3604483 /music/various/exodus/02-my_will__dc_talk.mp3 While the music is playing, there is an additional copy of the mp3 open but instead of 3r or 5r, it's tagged as mem (memory-mapped access I assume). Anyhow, I've worked around it by 'quit'ting out and restarting the process, but I'd rather spawn the background process once and not have to do that.
Created attachment 65285 [details] Patch that cures the leak for me
Just a comment about the above patch. Works for me, but since I know nothing about the subtleties of mmaping files it may be all kinds of b0rken.
Created attachment 65286 [details] A (possibly) more correct patch
The second patch appears to be correct. It behaves as I would expect it to according to lsof and it is, to my mind at least, a less invasive patch.
At this point, we probably won't fix mpg321 bugs.