To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 882
881  |  883
Subject: 
malloc() bug haunt: getting closer..
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Wed, 1 Mar 2000 11:52:15 GMT
Viewed: 
1478 times
  
Yesterday evening i found something, that might be the reason for some
of the crashes reported lately:

The chain of memory blocks used by malloc() has a broken entry, say: the
reserved block at 0xfd7c has a length word of 0xfffe. This will cause
malloc() and friends to behave unpredictably whenever that block is
encountered while running through the chain.
However, so far i couldn`t find the exact reason for this bad entry.
Strangely, if i enlarge the reserved area for the vector table somewhat
(in mm.h), the chain is constructed correctly, in fact there is a
threshold: If the start of the area is below the threshold, ( i think it
was 0xfb82, can't tell exactly because i'm at work now ) the chain is
ok, if it's above that value, the chain is broken.

My first assumption is a code generation problem with the MM_BLOCK_FREE
and MM_BLOCK_RESERVED macros. However, the generated code for both cases
(correct chain vs. broken chain) seems to be identical except for the
address the block header is written to and the length that is written to
the header. ( i'll try to check this more seriously this evening )
Currently i fear the chain is constructed correctly in mm_init() and
corrupted later, what would make the haunt a little harder again :-(

--
Dipl. Ing. Martin Cornelius
SCHENCK RoTec GmbH Darmstadt, Germany
Tel.: +49-6151-32-1121



1 Message in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR