bugAVR C Runtime Library - Bugs: bug #19445, _malloc_heap_end does not follow...

 
 

bug #19445: _malloc_heap_end does not follow _heap_end on m2561

Submitted by:  None
Submitted on:  Thu 29 Mar 2007 06:02:23 PM UTC  
 
Category: DocumentationSeverity: 3 - Normal
Priority: 9 - ImmediateItem Group: Documentation
Status: FixedPercent Complete: 0%
Assigned to: Joerg Wunsch <joerg_wunsch>Originator Email: -unavailable-
Open/Closed: ClosedRelease: None
Fixed Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 09 May 2007 09:48:23 PM UTC, comment #2:

I marked all variables in the documentation by *(__malloc...)
to distinguish them from the linker-added absolute symbols.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Thu 29 Mar 2007 06:41:03 PM UTC, comment #1:

As Dave Hylands already wrote on avr-libc-dev, __malloc_heap_end
is a variable that points to __heap_end, so you are only ever
supposed to handle _heap_end. The __malloc* variables are
what malloc() uses internally to keep track of the allocations
and boundaries.

This is basically also the way the documentation tells you,
but in retrospect, I agree the picture is a little misleading
here, and could express that clearer.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Thu 29 Mar 2007 06:02:23 PM UTC, original submission:

In a makefile I have (as per the avr libc docs):

override LDFLAGS = -Wl,--section-start,.data=0x802100,--defsym=__heap_end=0x80A0ff,-Map=$(PRG).map,--cref -lm -u vfprintf -u vfscanf -lprintf_flt -lscanf_flt -lm -lc

On an mega2561 w/ 8k internal, and 32k external. Been chasing apparent memory corruption for a couple weeks.

Ran avr-nm -n today, to find:

...
00803c0c D CommandSystemParamsSize
00803c0e D __thenan_sf
00803c16 D __malloc_margin
00803c18 D __malloc_heap_start
00803c1a D __malloc_heap_end
00803c1c b ResetSrc
00803c1c B __bss_start
00803c1c D __data_end
00803c1c D _edata
00803c1d b Disp3Ct
00803c1f b LimitStateArray
...
00805ddc B _FF_ScanAddr
00805de0 B __iob
00805de6 B __brkval
00805de8 B __flp
00805dea B __bss_end
00805dea A __heap_start
00805dea A _end
0080a0ff A __heap_end
00810000 A __eeprom_end

I'm looking at the avrlibc docs right now, and they seem to indicate that my makefile should be instructing both heap_end and malloc_heap_end to be at 0x80A0FF.

Then last night I added:

override LDFLAGS = -Wl,--section-start,.data=0x802100,--defsym=__heap_end=0x80A0ff,,--defsym=__malloc_heap_end=0x80A0ff,--defsym=__malloc_heap_start
=0x8080ff,-Map=$(PRG).map,--cref -lm -u vfprintf -u vfscanf -lprintf_flt -lscanf_flt -lm -lc

And the memory corruption appears to have gone away.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by arcanum (Updated the item)
  • -unavailable- added by joerg_wunsch (Posted a comment)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 09 May 2007 09:48:23 PM UTCjoerg_wunschStatusNone=>Fixed
      Assigned toNone=>joerg_wunsch
      Open/ClosedOpen=>Closed
    Sun 06 May 2007 03:53:21 PM UTCarcanumPriority5 - Normal=>9 - Immediate
    Thu 29 Mar 2007 06:41:03 PM UTCjoerg_wunschCategoryNone=>Documentation
      Item GroupUnknown=>Documentation

    Back to the top


    Powered by Savane 3.1-cleanup1