SIGSEGV/SIGTERM/SIGBREAK Signals are not caught

[Valery V. Sedletski]

I have signals handler set up for some cleanup procedures in FORMAT/SYS/CHKDSK, like remounting the disk, but if I interrupt CHKDSK by Ctrl-Break, I see

^C
External process cancelled by a Ctrl+Break or another process

This is when running from UFAT32.DLL. But if I run the standalone version of CHKDSK, I get:

Signal 4 was received

and it cleanly remounts disk. In UFAT32.DLL case, we have disk in intermediary state (mounted in MOUNT_ACCEPT mode).

The cause, as I suspect, is that CHKDSK is a 32-bit program and sets up 32-bit exception handler, but CHKDSK routine is a 16-bit wrapper around a 32-bit "chkdsk" routine. So, we indeed run 16-bit routine, but an exception handler is 32-bit. This seems to be inconsistent, and thus, the 32-bit exception handler doesn't activate. So, we need a solution for this problem.

[Valery V. Sedletski]

Hm, strange. Now standalone CHKDSK version won't execute signal handler. Tried to set up signal handler in 16-bit wrapper, but it still doesn't activate in UFAT32.DLL case.

[Valery V. Sedletski]

Setting up the signal handler in DLL init routine doesn't help too. Very strange.

[Valery V. Sedletski]

In r207, I added 16-bit signal handler. Now CHKDSK/FORMAT can be interrupted if running CHKDSK.COM/FORMAT.COM 16-bit frontend programs. What is interesting, with CHKDSK.EXE, the 32-bit frontend program from osFree project, if I press Ctrl-C, the 16-bit signal handler is activated too. So, this depends on the fact that CHKDSK entry point is 16-bit, not the fact that CHKDSK.COM frontend program is 16-bit.

Also, help screens are added in CHKDSK and SYS routines, they are shown if you run "chkdsk x: /?" or "sysinstx x: /?". Or, "/h" could be used, instead of "/?".

Also, I added support for backing up the chkdsk.log to chkdsk.old.

The updated version is available at the fat32 main page.

[Valery V. Sedletski]

Now Ctrl-Break or Ctrl-C is caught by the signal handler. SIGSEGV traps catching doesn't work because it seems to be no corresponding 16-bit signal/exception. (the set of 16-bit exception is limited, compared to the 32-bit ones). So, I'll close this ticket.