Message-ID:	<3EB003EF.B018691F@yahoo.com>
Date:	Wed, 30 Apr 2003 13:12:15 -0400
From:	CBFalconer <cbfalconer AT yahoo DOT com>
Organization:	Ched Research
X-Mailer:	Mozilla 4.75 [en] (Win98; U)
X-Accept-Language:	en
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: uclock again
References:	<Pine DOT UW2 DOT 3 DOT 95 DOT 1030430093149 DOT 11724A-100000 AT bryggen DOT bgnett DOT no> <3EAFA264 DOT 18185C7B AT yahoo DOT com> <00fa01c30f0a$a0d4dc20$0600000a AT broadpark DOT no>
Reply-To:	djgpp-workers AT delorie DOT com

Gisle Vanem wrote:
> 
> "CBFalconer" <cbfalconer AT yahoo DOT com> said:
> 
> > 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.
> 
> But not before the next malloc/free operation if guess. That
> doesn't me when the rmcb-stub of the real-mode callback
> messes up. Is there an interrupt safe function I can use to
> test this with?

I am confused - I think there is a language barrier.  With the new
package you can passively test the heap at any time with
malloc_verify, which could be used to isolate non-heap operations
gone amuck in the heap arena.

  /* known sound here */
  for (....) {
    /* operations */
    if (!malloc_verify) operationsfouledup();
  }

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