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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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!