Hi! >> --- kernel/memmgr.old 2006-08-18 10:22:33.000000000 +0200 >> +++ kernel/memmgr.c 2006-08-18 10:22:33.000000000 +0200 >> @@ -66,7 +66,12 @@ >> /* join both MCBs */ >> p->m_type = q->m_type; /* possibly the next MCB is the last one >> */ >> p->m_size += q->m_size + 1; /* one for q's MCB itself */ >> +#if 0 /* this disturbs QB 4.x double-free... */ >> q->m_type = 'K'; /* Invalidate the magic number */ >> +#else > + q->>m_type = MCB_NORMAL; /* make QB 4.x happy... */ > + q->>m_psp = FREE_PSP; /* leave MCB as "valid but free" */ >> +#endif >> }
> q->>m_type = MCB_NORMAL; /* make QB 4.x happy... */ > is not a good idea (could also be MCB_LAST). just leave it as it is As it is not linked / in use anymore, it makes no difference... > q->>m_psp = FREE_PSP; /* leave MCB as "valid but free" */ > is necessary (it's already free) I think you wanted to say "is not necessary". And you are right. > leaving > +#if 0 /* this disturbs QB 4.x double-free... */ > q->m_type = 'K'; /* Invalidate the magic number */ > +#endif > as the patch I'd recommend Okay... > OTOH, now imagine a program > memptr = dos_alloc(100); > dos_free(memptr); > mem2 = dosalloc(10); > dos_resize(memptr,200); /* which will ALSO take ownership of THIS block */ Okay, so you mean RESIZING a block after FREEING it can cause havoc? This is true, but would MS DOS survive this? Basically the updated patch means "free MCBs become unlinked when their memory is merged with the memory of adjacent free MCBs, but thear are no longer invalidated". Quite clean... But okay it no longer traps the "resize freed block" case. How about marking free blocks as unresizable at the moment when joinMCBs splices them out of the chain, leaving an unlinked but "double-freeable" data structure in RAM? I imagine you could set m_size to -1 to mark a (former / unlinked) MCB as unresizable. Such a MCB would link to itself (seg+1+-1==seg) and can be identified as "fake" MCB that way. DosMemFree should accept "valid but fake" MCBs (for QB compatibility) while DosMemChange and the rest must only accept "valid nonfake" MCBs. Again, I would like to know how MS DOS reacts to resizing freed MCBs. I somehow hope that double-free is as bad as it gets, and that no programs do free-then-resize. > so IMHO in general your patch is not a good idea to do. > but of course you could have a kernel_config option > sys config BRUN40_COMPATIBLE=1 Of course I vote for this to default to 1 ;-). But then, it would really be better to implement a patch which can always stay on. For example the "valid but fake, double- freeable but not resizable" method described above. Eric ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
