Bug 4036 - VMs can clog up sourceFile buffers
Status: RESOLVED WONTFIX
Alias: None
Product: ioquake3
Classification: Unclassified
Component: Misc
Version: GIT MASTER
Hardware: All All
: P3 minor
Assignee: Zachary J. Slater
QA Contact: ioquake3 bugzilla mailing list
URL:
Depends on:
Blocks:
 
Reported: 2009-04-08 14:17 EDT by /dev/humancontroller
Modified: 2009-09-14 07:29:20 EDT
1 user (show)

See Also:


Description /dev/humancontroller 2009-04-08 14:17:56 EDT 
When the cgame/game/ui gets unloaded, we should automatically close all related sourceFiles[i], otherwise some files will remain open forever.

When forcefully unloading a VM, CL_InitUI() gets called. Why? forced_unload is set! If the UI fails to load, we're toast.
My scenario is that Tremulous' cgame forgets to close some sourceFiles[i]. At some point all 64 file slots will appear to be in use, and UI_LoadMenus() (in UI_Init()) will fail to open the menus.txt file, and call Com_Error() with "default menu file not found: ui/menus.txt" [where "not found" should have been expressed as "failed to open"].

Perhaps use separate sourceFiles for each VM?
Comment 1 Ludwig Nussel 2009-05-08 05:12:30 EDT 
isn't that a problem with file in general? vm's can call trap_FS_FOpenFile and there is no close on unload handler AFAICS.
Comment 2 /dev/humancontroller 2009-05-08 11:16:19 EDT 
(In reply to comment #1)
> isn't that a problem with file in general? vm's can call trap_FS_FOpenFile and
> there is no close on unload handler AFAICS.

Yes it is a q3-filesystem problem. I just brought up an example of the ui appearing to be borked because the (actually borked) cgame doesn't close its opened files, all because the file slots are shared. So I propose to make separate sourceFiles[] for each VM, and auto-close the appropriate ones on VM unload. OK? I can make a patch if yes.

("When forcefully unloading a VM, CL_InitUI() gets called. Why? forced_unload is
set! If the UI fails to load, we're toast." ... that's related only to the scenario, not this bug.)
Comment 3 Tim Angus 2009-09-14 07:29:20 EDT 
Sounds like you're proposing basically garbage collecting file handles. I'm never sure that's the correct thing to do in an unmanaged resource system as you're then going to end up masking legitimate bugs. Best to let it leak so the evidence of any problems is still there, then fix the problems.