Mail Archives: djgpp-workers/2003/04/30/06:23:36
Gisle Vanem wrote:
> 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?
IF you are referring to nmalloc, it always allocates in multiples
of 8, and any such overrun will write into the prv field. The
result will immediately be detected by malloc_verify if the
stack_length above is a multiple of 8 or less than 4 smaller. In
many cases it should also be eventually caught by routine
operation (i.e. no malldbg/malloc_verify in use) of nmalloc with
the message "memory fouled" to stderr and a SIGABRT.
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -