[hatari-devel] Hatari's GEMDOS emulation

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

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. 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.

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
- 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.

Conclusion: that handling of the dta access should be reworked.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/