Red Hat Bugzilla – Bug 68788
really big playlists eventually exhaust available process filehandles
Last modified: 2014-03-16 22:28:54 EDT
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
mpg123 1138 reddirt 3r REG 3,9 7273485 2179082
mpg123 1138 reddirt 5r REG 3,9 9556953 3604483
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.