Date: Fri, 10 Aug 2001 11:41:32 +0300 (WET) From: Andris Pavenis To: Charles Sandmann Cc: djgpp-workers AT delorie DOT com Subject: Re: Selector Exhaustion In-Reply-To: <10108100454.AA13597@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Thu, 9 Aug 2001, Charles Sandmann wrote: > This is my patch vs cvs: > > *** dosexec.ori Wed Aug 1 20:33:04 2001 > --- dosexec.c Thu Aug 9 23:34:58 2001 My own patch (checking all descriptors using __dpmi_get_descriptor_access_rights(), repeating the test after running program and trying to release ones which have been newly appeared) works nicely under Win98SE but not under WinNT 4.0+SP6. Blind releasing area of descriptors like in Your patch (potentially dangerous as we're assuming specific descriptors allocation order) works much better under WinNT 4.0+SP6: executable spawned other DJGPP program more than 2500 times without descriptor leak So it looks that: for Win9X we can scan all possible descriptors to see which ones are additionally allocated after return from child process to free them after that. Such way is verified to work Ok under Win98SE and under DOSEMU-1.0.2 (Linux kernel 2.4.7) It looks that under WinNT 4.0SP6 freeing descriptor does not change it access rights so I don't see a simple way how to find which descriptors are in use before running child process. So it seems that blind freeing descriptor inside such interval is best we can do. Perhaps it's too dangerous to enable such blind releasing descriptors by default, so I think some option in startup flags (default off) could be added. There is no problem for Win9X and DOSEMU as we can find which descriptors are newly allocated by spawned program. > > So, my problem with selectors went away with the above patch, but now I > die due to no DOS memory :-P (it does run longer). Now what is strange > is before I added the diagnostic print I think I still leaked, but I > can't be 100% sure my make build was correct. So, does NTVDM leak dos memory > too? As I said my test program spawned more than 2500 processes under WinNT 4.0+SP6. However I cannot test that with Win2k Andris