Mail Archives: djgpp-workers/2001/08/10/04:57:26
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
- Raw text -