Hi,
On 11/26/2016 11:12 AM, Thorsten Otto wrote:
Yesterday, i had some weird crashes of a program that i'm currently
writing.
In the end, it turned out to be a bug in the program, but it only
manifested
itself in Hatari, StonX and Aranym worked fine. The crash happened at
$fa00dc,
that is in the cartridge routines which are used for the GEMDOS
emulation.
Cartridge part is used for GEMDOS HD Pexec() emulation, because it
requires asking emulated TOS to allocate new basepage, and it's
easier from emulated code than emulator itself.
To be more precisely, that is near the end of find_prog. That routine
does a
Fgetdta(), copies the DTA structure to the stack, calls Fsfirst, then
copies
the structure back. It crashed writing to address $4, when writing the
last
two longs back, which indicates that Fgetdta() got a null pointer.
I think it indicates that either program basepage, or DTA value
in it was invalid.
Fsfirst() call goes to GEMDOS HD emu, which gets DTA from basepage,
and does some checks for it, and call fails if those checks don't pass.
You should see warning about that in console.
Which TOS version you're using and was the Pexec() done by TOS desktop
or something else?
While further investigating, i noticed that in gemdos.c there is only
a single
DTA pointer maintained. This is definitely not quite right, every
process has
it own DTA address. Assume a situation like:
- Desktop calls Fsetdta. The address is remembered in gemdos.c
- Desktop executes a program.
- Program calls Fsetdta. The address is remembered in gemdos.c
As far as I can see, the stored value is never used
(except for saving it redundantly to memory snapshot
so that it can be restored).
Only value from Fsetda() seems to be getting slightly
earlier warning about invalid DTA. Could be removed
too.
See the attached GEMDOS HD emu cleanup patch.
How others on the list feel about those changes, any
comments / objections?
The other patch adds initial "info dta" command to debugger,
with which one can investigate also non-GEMDOS HD DTAs.
- Program exits.
- Desktop calls Fsfirst, without setting the DTA pointer again. That
call,
when emulated in gemdos.c, will now access the DTA that was set by the
program, which is no longer valid.
A similar situation will occur when the Program calls Fsfirst without
calling
Fsetdta. In that case, the DTA structure of the Desktop will be used.
However,
every new process has its initial DTA set to the basepage's command
line (at
least with TOS, dunno for MagiC). That initial address is not set with
Fsetdta, it is only set by manipulating the p_dta member of the
basepage, so
Hatari does not catch that.
If you'll read gemdos.c more closely, you'll notice that the DTA
pointer is on every Fsfirst() & Fsnext() refreshed from basepage.
Only thing that's not refreshed from TOS side, is DTAIndex index
to internal DTA array.
Conclusion: that handling of the dta access should be reworked.
It definitely has too many global variables, code would
be clearer if few of them would be passed as arguments.
- Eero