Hello Bart,
thanks for offering to help. I now pushed a GCC-portable version of
Tom's stack check to freecom's git:
https://github.com/FDOS/freecom
However if you try to compile it you'll see once you run it that it
says 0 stack left quite quickly. The reason is not the stack (there is
plenty) but the heap which grows towards the stack. The default heap
is very small though (6K), still it grows much further than OW's (with
OW the stack is below the heap though but I debugged it a few times).
Thanks for the information!
I added some further debugging lines --- for temporary use --- to try to
show how the heap top address (sbrk) changes over time, and to highlight
to the user whenever there is a huge jump in the sbrk:
https://gist.github.com/tkchia/c27c47e85550914e37ca85f82952f015
When I run the patched command.com with metados.img, the sbrk gets a
huge jump (from 0x18d8 to 0x21e0) around the time of the exec( ) call on
the command "xmssize.com 5 >NUL". I find this very strange (since I do
not expect exec( ) to need to mess with the heap).
There is another huge jump in the sbrk (0x21e0 -> 0x2dd0) around the
cmdptr->func( ) of "dir /s/a-d/b a:\fetchbat.zip".
It seems this is not merely a case of the heap becoming too fragmented
and growing too fast --- though I am not sure yet what it actually is.
Thank you!
--
https://github.com/tkchia/
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
