Hi! I think there should be a separate subject for this topic: https://gitlab.com/FreeDOS/issue-reporting/-/issues/14#note_2686589554 https://github.com/FDOS/kernel/issues/210 It seems that the test kernel which preserves FS and GS segment registers in the critical error handler has fixed this, but the issue discussion is asking for more testers :-) Thanks! Regards, Eric
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
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
