Hello Bart,
now if the size of command.com in memory ever changes,
to little is saved/restored.
I think it is related somewhere to MCB corruption but still not sure where.
Somehow it happens after the strings are copied back in from XMS. I`ll
still have to dig deeper.
I have just checked in to GitHub some patches for Newlib (for the GCC
toolchain) to beef up the memory corruption checking and error reporting
in abort ( ) and the nano-malloc _free_r ( ). These will hopefully help
a bit towards diagnosing
When I recompiled FreeCOM with the patches, and rerun `fetch mem' with
the METADOS image + FreeCOM, the reported dumps seem to suggest that
freep ( ) was trying to free a dynamic string whose malloc ( ) chunk
size was somehow corrupted, to a value larger than a size_t (!).
(I believe that some of the MCB corruption that was occurring before was
the result of leaving this size corruption unchecked --- the _free_r ()
would "return" an overly large block to the free list, and the anomaly
would then bleed to the rest of the command.com data segment, including
the MCBs after the stack end.)
I have not yet managed to trace further backwards to what caused the
corruption in the first place.
Thank you!
--
https://github.com/tkchia
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
