Date:	Wed, 30 Apr 2003 09:49:43 +0200 (MET DST)
From:	Gisle Vanem <giva AT bgnett DOT no>
To:	djgpp-workers AT delorie DOT com
Subject:	Re: uclock again
In-Reply-To:	<10304300444.AA21224@clio.rice.edu>
Message-ID:	<Pine.UW2.3.95.1030430093149.11724A-100000@bryggen.bgnett.no>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 29 Apr 2003, Charles Sandmann wrote:

> @@ -30,4 +49,38 @@
>    uclock_t rv;
>  
> +  _farsetsel(_dos_ds);

This modifies FS, right? And libc code uses GS? 

I just stumbled across a RMCB bug that only occurs under Win-XP;
a packet-driver that uses the FS/GS registers (and assumes the 
callback saves them). But AFAICS, the gormcb.c code doesn't save 
and restore those registers. So the int 1B handler may also cause
havoc.

Another thing, the stack value set in wrapper_common[] sets
ESP to 'malloced_stack + stack_length'. According to my doc's an 
i386 decrement ESP *after* a push (opposed to an 286). So the 
malloc() area is overwritten by 4 bytes. To make thing worse; the 
allocation is a multiple of 8 (ALIGN), so I guess some other area 
will choke. At least I got crashes and tracebacks in strange areas
(end+0ff??).

Don't know if problem manifested itself due to the new malloc code
or what. Sorry I don't have the details here now (I'm writing this 
in Pine on my ISP shell-account via Watt-32 telnet client). 

Whadda you say? Is there some bug lurking here?

--gv

- Raw text -