> I ask this because some recent activity by Bernd and ECM who have been
> working on a kernel Divide by Zero error.
>
> Very, very, very basically, part of the 32-bit kernel was assuming the GS
> register would remain unchanged. But, the buffer was moving because of that
> register.
Now that it comes up on the mailing list: I do not think that the DOSLFN thing
is connected to the mentioned "divide by zero error".
We detected a flaw in the critical error handler, which makes it destroy the
kernels FS and GS content. This is only for the Watcom 386 flavour of kernel
builds.
One symptom of this bug was a division by zero error when listing directory
entries after a critical error was triggered. This resulted from a memory
corruption in kernel HMA space which altered kernel code.
We fixed it in the following way (no merge request as of now at the Github
repo):
diff --git a/kernel/entry.asm b/kernel/entry.asm
index 47316d6..d6a944b 100644
--- a/kernel/entry.asm
+++ b/kernel/entry.asm
@@ -611,6 +611,8 @@ CritErr05:
mov bp,sp
push si
push di
+ Protect386Registers
+
;
; Get parameters
;
@@ -715,6 +717,8 @@ CritErr30:
CritErrExit:
xor ah,ah ; clear out top for return
+
+ Restore386Registers
pop di
pop si
pop bp
Greetings, Bernd
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
