Re: [hatari-devel] Problem with Hatari 1.6.2 and EmuTOS 192K ROMs

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On perjantai 12 lokakuu 2012, Vincent Rivière wrote:
> On 12/10/2012 20:56, Roger Burrows wrote:
> > Some kprintf's in the EmuTOS code makes me suspect that it's crashing
> > on a call to Gettime(), but I haven't tried to narrow it down further
> > via EmuTOS.
> 
> Indeed, I had similar clue.
> 
> I ran the official Hatari 1.6.2 Windows binary with some debugger.
> I crashes with an Access Violation exception due to a NULL pointer.
> 
> My magic wand indicates that it crashes just after the call to
> IKBD_AddKeyToKeyboardBufferWithDelay(0xFC, 32000) inside src/ikbd.c,
> function IKBD_Cmd_ReadClock().

Thanks!


> The only pointer used there is SystemTime, which comes from
> localtime(&nTimeTicks). This would suggest that localtime() returned
> NULL.

According to POSIX specification, the returned pointer (when there isn't
an error) points to a static structure, so it cannot be an allocation
error.


> I let Hatari developers to investigate how this could be possible
> (bad nTimeOffset?).

According to Microsoft documentation, NULL is returned by localtime()
if the given time points before Epoc (January 1, 1970):
http://msdn.microsoft.com/en-us/library/aa246456(v=vs.60).aspx

time_t is time in seconds since epoc, a signed long int.

I.e. the value of nTimeTicks was negative here:
--------------
static void IKBD_Cmd_ReadClock(void)
{
        struct tm *SystemTime;
        time_t nTimeTicks;

        /* Get system time */
        nTimeTicks = time(NULL) - nTimeOffset;
        SystemTime = localtime(&nTimeTicks);

        /* Return packet */
        IKBD_AddKeyToKeyboardBufferWithDelay(0xFC, 32000);
        /* Return time-of-day clock as yy-mm-dd-hh-mm-ss as BCD */
        IKBD_AddKeyToKeyboardBuffer(IKBD_ToBCD(SystemTime->tm_year));
....
--------------

According to MSDN, time() doesn't return negative value
(although it could do that according to POSIX if given
invalid non-NULL pointer, but here we use NULL).

I.e. the problem must be nTimeOffset value that is larger
than current time.

However, nTimeOffset is zero unless some other value is:
* Set to it by IKBD IKBD_Cmd_SetClock() call
* Loaded to it from a memory snapshot


Does EmuTOS call IKBD_Cmd_SetClock() before IKBD_Cmd_ReadClock()
with some wierd value?

Or have you enabled in your Hatari configuration memory state
autosaving/loading feature?


In any case, I think we need to add some WIN32 check for negative
nTimeTicks value.

GEMDOS Tsetdate() supports only dates after 1980, so I guess limiting
IKBD date values to 1970 or later would be pretty safe bet even without
WIN32 ifdef, unless there's some wierd Atari code that relies on
older IKBD dates...   Nicolas?


> By chance, I noticed that the EDI register value was 0x00FC4968, which is
> an address inside the EmuTOS ROM. It is the return address of ikbdws(),
> called by gettime(). This confirms both Roger's findings and mine.
> 
> Not that this crash does not occur with my non-standard Hatari build on
> Cygwin (which uses NewLib as libc, instead of MinGW). So probably
> different localtime() implementation.

Isn't Cygwin supposed to implement POSIX whereas MinGW is
wrapper around Windows libraries?


	- Eero