ESCape issue with 1.1.3.2
Hello.
Quoted 3 lines · Bart Oldeman
Quoted 2 lines
I think this will cause a null
pointer dereference later inYou are right;
I think that the real problem with this is that as soon as the low mem is mapped, we are no longer receive a SIGSEGV on a null dereference, so such dereferences may be unnumbered all around the code...
Quoted 2 lines
here's a second fix (including the hitimer stuff for various cases, which in turn includes a fix from you
Actually when I have found that overflow in miscemu.c (which later turned out to be a miscompilation of gcc-2.96-RH) I searched and looked into the keyboard case and even those lock-up reports came to my mind, but I considered that code to be safe (the t_dif might not exceed the src_tv.tv_usec value).
Even now I don't see how it can overflow, but well, maybe I am overlooking some corner cases, let's see if it fixes the problem...
Quoted 6 lines · Stas Sergeev
I think that the real problem with this is that as soon as the low mem is mapped, we are no longer receive a SIGSEGV on a null dereference, so such dereferences may be unnumbered all around the code...
yes, could well be. I can think of two possibilities to get trap anyway.
a) r/w protect the first page (first 4K) while DOSEMU is active (not in vm86/DPMI). Then it needs to protect/unprotect around updates of the BIOS data area (at 0040:0000-00ff). That's bad for performance (though that is less of an issue for debugging). Fortunately this should not be that hard to program becuase most of the BIOS data area r/w's are done using macros, so you only need to change those.
b) set a hardware watchpoint for address 0. That can be done using "awatch (*0)" in gdb. But gdb does not play well with DOSEMU in this respect. Somewhere the debug registers must get trashed.
Bart