crash when terminating self-parented shell #97
Comments
|
I've found the ingenious way of recovering the |
Your reading of RBIL is correct. However, it doesn't mention in your quote that opened file handles also are not closed. With the following code executed in "2.0pre8-20190715-1151-gde1667e74" running "FreeDOS kernel - SVN (build 2042 OEM:0xfd) [compiled Sep 22 2017]" it seems to work fine: Here are the revisions of the debugger used: |
Please give a specific test case so I can check.
But when a PSP is terminated that is self-owned, then both the current PSP (during start of the call) and the parent PSP are the same..?
|
|
"command.com /P" then "exit" does, as it is supposed to, nothing. Again 2.0pre8-20190715-1151-gde1667e74 running FreeDOS kernel 2042, and "FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]". |
|
Hmm, "exit" in that case doesn't seem to go through process termination. Manually entering the termination of "command.com /P" through lDebug "TSR" mode then "g=psp:0" results in the message: |
Test-case is comcom32 without this patch:
If you mean real parent rather than self-parent, |
|
Stepping into the Int20 or Int21.00 or Int21.4C or PPI (Parent Process Interrupt 22 entrypoint, dword at offset 000Ah in current PSP) of FreeCOM (no /P) also doesn't lead to a crash, it just terminates the FreeCOM instance. This shows that the FreeCOM PSP is 02CCh, and the stored Int22 in the FreeCOM PSP points to 02DCh:0A0Ch, ie into FreeCOM's resident portion. This shows (albeit I didn't use the proper command for it) that FreeCOM's PSP is self-owned, word [02CCh:0016h] is equal to the PSP address (02CCh). |
I do mean self-parent. I debugged your test case with the attached file, turns out it doesn't self-parent itself properly: PPI (the running current PSP's dword at 000Ah) should point into a COMCOM32 handler, not the actual parent FreeCOM's. |
|
Just to check that we are actually self-owned: PPR is the Process Parent Process. |
|
So why 0a should be changed? |
You should touch it, that's how to self-parent a process. DEBUG does the same, it sets up one int 22h handler for when its child debuggee process terminates (at https://bitbucket.org/ecm/ldebug/src/adab3da5025ff00b63381aec2d50bcee150989a8/source/run.asm#lines-4396 ) and another for when DEBUG itself is terminated through Ctrl+C or critical error or whatever (at https://bitbucket.org/ecm/ldebug/src/adab3da5025ff00b63381aec2d50bcee150989a8/source/debug.asm#lines-1305 ). I don't know why PC-DOS doesn't crash, but it is not supposed to work that way. |
|
The links do not open. |
|
Not sure what is wrong about the links. Here's FreeCOM's interrupt 22h handler (that it installs into its own PSP's PPI): https://github.com/FDOS/freecom/blob/81535436f80343d7d111df381f2f9020bd1e3362/shell/cswap.asm#L216 |
|
This is where it is installed. Oddly enough, it only seems to do this correctly if XMS swapping is enabled. https://github.com/FDOS/freecom/blob/b0e598470a116d5c588e3836c443730cdbe98221/shell/init.c#L191 |
|
So basically it seems to restore the parent and
Yes, and the fact that no crash happens on |
Yes, if to terminate. In case of /P it jumps to the halting message. In case of DEBUG, it just re-initialises the debugger shell and executes the default input loop.
I guess so, but the fact that you report crashes on FreeDOS likely means that FreeCOM without XMS swapping would fail too, so FreeCOM is probably just not well maintained. |
I never did so. The crash was only on comcom32
That is one possible conclusion. |
I was referring to these crashes, yes. Conjecture is that FreeCOM without XMS swapping enabled would fail similarly on FreeDOS, if comcom32 crashes when PPR is hooked but PPI isn't.
You should set up a return handler, at least one that terminates the shell (ie, restores PPI and PPR and then terminates again). You can use DPMI services or DJGPP functions to allocate V86 Mode memory then write a blob into it, and link in the blob's target as the PPI. |
|
Here's a suggestion for the blob, just have to assemble that, store the parent in PSP:0070h, parent return address in PSP:0074h, and link this blob into the parent return address field. |
|
Why would I want to do that?
|
|
So would it be possible to investigate if |
|
Or if it is documented somewhere, would be |
|
I need to know that because in this case I |
|
Is there an easy test I can automate, i.e. run x.com see crash or print success? |
|
You need to take the comcom32 above and |
|
Nope, two reasons, it's easier for me to do it that way rather than run by hand n times, and I also don't know what I'm doing with ldebug etc. |
|
You don't need any kind of ldebug or whatever. |
|
Here are the tests, first with std command.com (on FDPP that means FreeCOM) and second with the first version of comcom32 you posted. These comcom32 all fail because I was expecting to be able to echo success after exit (I thought exit did nothing in the parent shell) Anyway have a look, if you can think of a better way of detecting success I'll rerun |
|
FreeDOS 1.20 does crash on exit. |
|
So I suggest to start another command.com
Good. Any other dos to behave similar way? |
|
Only a few DOS seem to support the Here's DR-DOS 7.03 |
Wow! You already applied my djgpp patch? Does DR-DOS error on |
|
Maybe there is another work-around though. |
|
Nope, I just ran your comcom32.exe. That DR-DOS didn't have the problem with set in config.sys, I believe v6+ supports it. |
Ah, so I built it with the patch...
So do you mean it actually sets the env and you |
|
Here's comcom32 run config.sys |
|
I think you can just start it by hands from |
|
Maybe even |
|
|
Success. |
|
And the first hang was likely because DR-DOS |
|
any other DOS you want me to try in the same fashion? |
|
A few MS-DOS versions, and that should be it. |
|
Or it may be better to try with freecom as a |
700 and 710 are crashing without even running comcom32, just native shell. I suspect that's unrelated |
|
Wow, regression. So basically only freedos crashes on exit? |
|
Yes I used to run the tests regularly and all DOSes were pretty much okay, but I stopped doing that. I just checked my Jenkins server and apparently they were okay 1 year & 7 months ago. I didn't try rxdos for a long while now as I never added it to the test suite. I think that was because it was just a test image @ecm-pushbx rolled for me, rather than a specific release. |
Yes on the DOSes I've tested. |
|
OK, anyway, all DOSes but freeDOS seem to |
|
Thanks! |
|
So unless there are more evidences or a |
|
Had to revert that patch due to #123 |
|
2 interesting things.
|
|
Does anyone know if PSP:38h can ever be non-zero? |
|
It appears that this problem is actually So the fix on fdpp level is not needed. |
If the shell with self-parented PSP terminates,
fdpp crashes. I checked that FreeDOS crashes too
but PC-DOS not.
The crash is because user's registers are popped
from the stack pointed by PSP:2e, and if PSP didn't
switch to parent's, then the parent will get the
control but with all registers from child. Since this
is a shell, the parent is DOS itself, and in the case
of fdpp/FreeDOS it can't recover after losing all
registers.
@ecm-pushbx could you please explain is it legal
to terminate with self-parented PSP? RBIL only says:
Which implies that it is perfectly legal.
But if so, how should the registers be restored on
such termination? Does anyone know?
The text was updated successfully, but these errors were encountered: