Bug: Mapinfo file descriptors not being closed

[XtremeBain]

So I was taking a look at `lsof` for something else and noticed that my PB servers are leaving the mapinfo files in an open state for every map that was played on a server.

These servers are running on x86 linux, the server spawns with pbcup and pbcup is the only map in the rotation.  The first bunch is my match1, which has played a few maps since the servers were restarted.  It still has a FD open for each of the maps it has played.  Unless this is some way to cut back on memory usage, it's probably not the best idea to have these floating around forever, unless you've got something that removes stale ones.

COMMAND     PID      USER   FD      TYPE     DEVICE     SIZE       NODE NAME
paintball 24216     userx  txt       REG        8,2   563179   15400973 /home/userx/paintball2/paintball2
paintball 24216     userx  mem       REG        8,2   574086   15400997 /home/userx/paintball2/pball/gamei386.so
paintball 24216     userx    3w      REG        8,2   208556   15401082 /home/userx/paintball2/pball/qconsole27911.log
paintball 24216     userx    6r      REG        8,2       85   15433869 /home/userx/paintball2/pball/maps/mapinfo/pbcup.txt
paintball 24216     userx    7r      REG        8,2       75   15433773 /home/userx/paintball2/pball/maps/mapinfo/castle1.txt
paintball 24216     userx    8r      REG        8,2       65   15433898 /home/userx/paintball2/pball/maps/mapinfo/shazam22.txt
paintball 24216     userx    9r      REG        8,2       86   15433762 /home/userx/paintball2/pball/maps/mapinfo/blitz.txt
paintball 24216     userx   10r      REG        8,2       77   15433877 /home/userx/paintball2/pball/maps/mapinfo/propaint1.txt
paintball 24216     userx   11r      REG        8,2       65   15433870 /home/userx/paintball2/pball/maps/mapinfo/pbcup_renoir.txt
paintball 24221     userx  txt       REG        8,2   563179   15400973 /home/userx/paintball2/paintball2
paintball 24221     userx  mem       REG        8,2   574086   15400997 /home/userx/paintball2/pball/gamei386.so
paintball 24221     userx    3w      REG        8,2    63438   15401083 /home/userx/paintball2/pball/qconsole27912.log
paintball 24221     userx    6r      REG        8,2       85   15433869 /home/userx/paintball2/pball/maps/mapinfo/pbcup.txt
paintball 24221     userx    7r      REG        8,2       77   15433877 /home/userx/paintball2/pball/maps/mapinfo/propaint1.txt
paintball 24226     userx  txt       REG        8,2   563179   15400973 /home/userx/paintball2/paintball2
paintball 24226     userx  mem       REG        8,2   574086   15400997 /home/userx/paintball2/pball/gamei386.so
paintball 24226     userx    3w      REG        8,2    45462   15401084 /home/userx/paintball2/pball/qconsole27913.log
paintball 24226     userx    6r      REG        8,2       85   15433869 /home/userx/paintball2/pball/maps/mapinfo/pbcup.txt
paintball 24231     userx  txt       REG        8,2   563179   15400973 /home/userx/paintball2/paintball2
paintball 24231     userx  mem       REG        8,2   574086   15400997 /home/userx/paintball2/pball/gamei386.so
paintball 24231     userx    3w      REG        8,2    45384   15401237 /home/userx/paintball2/pball/qconsole27914.log
paintball 24231     userx    6r      REG        8,2       85   15433869 /home/userx/paintball2/pball/maps/mapinfo/pbcup.txt

Edit: thread subject

[jitspoe]

Oy!  Thanks for catching that.  Can't believe I overlooked it.  That probably explains why servers are sometimes unable to load files once a bunch of maps get added to rotation.

[y00tz]

Nice job XBain! Jitspoe would this fix constitute a build 20 pretest 2?

[XtremeBain]

I think it's safe to assume that it can be fixed and bundled with a linux release (since it's biggest effect is on dedicated servers).  He can update the official B20 Win32 release with the fixed gamex86.dll, it's not really something that needs to be re-tested on the client end, but it would be beneficial for the few people that run dedicated Windows servers 24/7.

I mean servers have been running with this problem for a long time now, and it's never sparked any attention.  It would only start to cause problem for multiple linux servers which are being run under the same user which happens to have ulimits in place for the FDs, and the servers would have to play a large number of different maps.  I didn't expect that this was something that could potentially solve any of the outstanding "random" problems, but it looked like a bug none the less.

[jitspoe]

I'll put it in the linux version, but I'm not going to bother with the windows one for now.  It'll be in the next release.  I don't feel like rebuilding the installers (not to mention I'm limited on time with all the stuff going on now).