add more error handling

[floriangit]

Note, that with this change I'm running into the SBRK FAIL, OUT OF HEAP (address wrap) message you added in:
#2134

As I'm puzzled why my changes would trigger that, I've created this PR.

[floriangit]

When I simply put an exit 0 at this position:
https://github.com/ghaerr/elks/pull/2180/files#diff-a315aa3faca9cc819bbc35f960bf9a47dd24420634950b50df8dd2a96dcb11f3L119

OUT OF HEAP still triggers. So I assume it has something to do with the filesize rather than its commands/code?

Edit: Yea, maybe. Before it was 3070 bytes and now it's 4229 bytes. Crosses a magic 4096 (page?) size?

[ghaerr]

Try increasing /bin/sh's heap size in elkscmd/ash/Makefile. It's set to 12k to try to keep the resident working set small since at least one shell is almost always running. This can be fine-tuned later if this is found to be the issue. The shell data segment is also alway duplicated entirely on 'fork' so keeping it small helps run programs when memory is extremely tight.

Regarding the changes to the script, I would recommend adding a -p option to mknod instead of using 'test' with all the duplicated script code.

Before it was 3070 bytes and now it's 4229 bytes. Crosses a magic 4096 (page?) size?

The 8086 has no notion of page size, since there is no MMU. However, /bin/sh itself could be requiring more heap with an increased script size, I am not familiar with the internals of shell script processing but can figure that out if this continues to be a problem.

The bin/sys script itself had been previously meticulously crafted down to below 3K bytes to keep the distribution image size smaller, since it is on every disk image. Of course, it will have to cross 3K with this enhancement, but can easily be made less than 4k bytes with the mknod -p change.

[floriangit]

Thanks for the input. I'll explore the -p option.
HOWEVER, I was digging around your (massive) alloc changes, which had not been on my radar before. So my bias was more that your changes broke something (sorry, haha) and I found:

In my feature branch I still find libc/malloc/v7malloc.c which you renamed/moved in #2176.

This makes me believe that I have not a synced source tree. When I switch to my master the file is away! My git tree was made synced with yours before I started creating the feature branch today. And git pull says up-to-date regardless of my branch or master. I'm a bit puzzled, maybe I need to learn more re. git which keeps sometimes surprising me.
Any hints?

If not, I think your comment sounds "it's kind of expected" and I will check the options your wrote.

[ghaerr]

maybe I need to learn more re. git which keeps sometimes surprising me.
Any hints?

I'm definitely not a git wizard, and don't normally like renaming files as I believe it might affect the searchability for file history.

If you think you're tree is screwed up, sometimes I will clone a new tree from start then move the cross/ directory over from the old tree so as to not have to recompile the GCC toolchain.

[ghaerr]

I was digging around your (massive) alloc changes,
In my feature branch I still find libc/malloc/v7malloc.c which you renamed/moved

Neither of the alloc changes should affect any of this since /bin/sh doesn't use v7malloc (now named dmalloc.c). I do believe it strange that your tree still has v7malloc.c, as that was renamed as you stated.