From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10304301228.AA22894@clio.rice.edu> Subject: Re: uclock again To: djgpp-workers AT delorie DOT com Date: Wed, 30 Apr 2003 07:28:21 -0500 (CDT) In-Reply-To: from "Gisle Vanem" at Apr 30, 2003 09:49:43 AM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Precedence: bulk > > + _farsetsel(_dos_ds); > > This modifies FS, right? And libc code uses GS? No, it's actually GS because of include of farptrgs in the non-modified part of the file the diff doesn't show. > 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. A workaround would be to manually save and restore FS/GS if they are modified. (I've always just written my own assembly wrappers for callbacks). Fixing the wrappers will be a real pain. > 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??). I think you have some other problem - this code has worked fine before. > 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). The new malloc code isn't in the library yet.