heap wächst höher als __heap_end

Der Linker kann dir da nicht helfen, die Verwaltung des Heaps
erfolgt ja nicht durch den Linker, sondern durch den Code von
malloc().

Es wäre schön, wenn du die Folge von malloc()- und ggf. free-()-
Aufrufen, die dazu führen, rekonstruieren könntest, und damit bei
der avr-libc einen Bugreport öffnest.  Dann könnte man versuchen,
den Bug zu finden.

hab mir jetzt nochmal die variable __heap_end & __heap_start ausgeben 
lassen :

die stimmen auch nicht :

__heap_start : 0xDEBB
__heap_end   : 0x00FF


wenn ich beide vars im programm beschreiben will, verändern Sie sich 
auch nicht !

>nun gebe ich __brkval  im Programm aus

> hab mir jetzt nochmal die variable __heap_end & __heap_start ausgeben
> lassen :

Poste mal den Code, mit dem du das machst. Vermutlich liegt nämlich da 
der Fehler.

1

extern T_WORD *__brkval;

2

extern T_WORD *__heap_start;

3

extern T_WORD *__heap_end;

4

5

6

// main()...

7

            UA1_OffBoardTransmit(D_UartChannelOffBoardA,sizeof(__heap_start),&__heap_start);

8

9

UA1_OffBoardTransmit(D_UartChannelOffBoardA,sizeof(__heap_end),&__heap_end);

10

           UA1_OffBoardTransmit(D_UartChannelOffBoardA,sizeof(__brkval),&__brkval)

UA1_OffBoardTransmit(CHANNEL,ANZAHL_BYTES,&DATEN);

also die fkt. UA1_OffBoardTransmit will die adresse der zu übertragen 
daten haben

hab jetzt über  richtige Variablen  ausgeben lassen :

also     unsigned int brkval;
         brkval = __brkval;
         UA!_offBorardTransmit(xxx,sizeof(yyy),&brkval);


====================
heap_start :  0xFFFF
heap_end :    0x00EF
brkval :      0xFFFF

> hab jetzt über  richtige Variablen  ausgeben lassen :
>
> also     unsigned int brkval;
>          brkval = __brkval;
>          UA!_offBorardTransmit(xxx,sizeof(yyy),&brkval);

brkval = __brkval;
->
brkval = (unsigned int)&__brkval;

was soll das ? brkval ist doch ein pointer!

wenn dann  so oder  :

brkval = (unsigned int *)&__brkval;  und dann in der UART-funktion nur 
brkval schreiben ...

Nein!

__heap_start ist ein Symbol, also eine Adresse im Speicher.
Wenn du es gerne als Variable sehen möchtest, dann ist das eine 
beliebige Variable, die an dieser Adresse im Speicher steht, also 
z.B.:

extern uint8_t __heap_start;
Das erste Byte des Heap.

extern uint8_t __heap_start[10];
Die ersten 10 Bytes des Heap.

extern int * __heap_start;
Die ersten beiden Bytes des Heap bilden einen Pointer auf irgendein int.

Nachtrag:

Was du da also ständig ausgibst, ist nicht die Adresse des Heap-Anfangs, 
sondern das, was an diesem Heap-Anfang im Speicher steht, also die 
ersten beiden Bytes des Heap.

Hmm, für __brkval sollte deine Vorgehen allerdings richtig sein, denn da 
interessiert dich ja gerade der Inhalt.
Sorry dafür.

..schönen dank .

also haut hin ..  allerding ist heap_start bei 0x7CBA

aber brkval bei 0x7CB6 (vor heap_start) , das ist doch auch schonwieder 
dreck!

hab alle drei symbole nach deine o.g. methode ausgegeben

im mapFile steht bei 0x7CB6  __brkval

was soll nun ein symbol sein ??
( das sind alles dreis solche symbole??)
 an der adresse des symbols ( im falle __brkval: 0x7CB6 )  steht ein 
integerwert der die adresse speichert wo sich das momentane heapende 
(also das belegte Ende) ?

ist da jetzt richtig oder wie ?

ah ok ...   habs jetzt erst gelesen !


was ist nun der unterschied zwischen den Variablen/symbolen 
"__brkval" und "__heap_start/end" ??

> aber brkval bei 0x7CB6 (vor heap_start) , das ist doch auch schonwieder
> dreck!

Das ist ok, denn __brkval ist nicht Bestandteil des Heaps, sondern eine 
"normale" Variable zur Verwaltung des Heaps, ist also Bestandteil des 
bss-Segments.

> was ist nun der unterschied zwischen den Variablen/symbolen
> "__brkval" und "__heap_start/end" ??

Der Unterschied besteht darin, was dich jeweils interessiert. Bei 
__heap_start und __heap_end interessiert dich die Adresse selber, bei 
__brkval das, was an dieser Adresse steht.

> an der adresse des symbols ( im falle __brkval: 0x7CB6 )  steht ein
> integerwert der die adresse speichert wo sich das momentane heapende
> (also das belegte Ende) ?

Ja (für __brkval), nur "adresse des symbols" ist nicht ganz richtig. Das 
Symbol ist die Adresse.

sorry das ich mich so dumm anstelle ...

aber __brkval beinhaltet doch die (absolute) adresse im speicher bis 
vohin der heap "gefüllt"  ist oder ???

und genau diese adresse will ich haben, nicht den inhalt dieser

> aber __brkval beinhaltet doch die (absolute) adresse ...
> und genau diese adresse will ich haben ...

Also den Inhalt von der Variable__brkval, also das, was an der durch das 
Symbol __brkval festgesetzten Adresse im Speicher steht.

war das jetzt ne frage ?

aus diese Abb. in diesem Manual ist glaub zu sehen das __brkval auf die 
"Füllung des Heaps" zeigt .

ich will eigentlich nur wissen, bis wohin ist der heap belegt. ist !

Re To wrote:
> war das jetzt ne frage ?

Nein, das war die Antwort auf deine Frage.
Jetzt mal ganz konkret:

1

extern uint8_t  __heap_start;

2

extern uint8_t  __heap_end;

3

extern uint16_t __brkval;

4

5

uint16_t AdrStart = (uint16_t)&__heap_start;

6

uint16_t AdrEnd   = (uint16_t)&__heap_end;

7

uint16_t AdrAfterUsedHeap = __brkval;

soo...

hab das mal komplett so gemacht wie du geschriebn hast :

heap_start : 7CBA
heap_end   : 7FFF
ABER brkval: BF92


auch komisch :  nach rest ist brkval entweder BF92 oder FF92.

__brkval wächst dann in 4(byte) schritten  wenn  malloc(1); ausgeführt 
wird .

das highbyte ist nur immer anders ...

Re To wrote:

> auch komisch :  nach rest ist brkval entweder BF92 oder FF92.

> das highbyte ist nur immer anders ...

Das Adresslatch deines Externspeichers wird wohl ein Problem
haben.  Da brauchst du dich dann auch nicht wundern, warum das
malloc() nicht das tut, was es soll.  Das verlässt sich natürlich
schon drauf, dass eine einmal gesetzte Variable beim nächsten
Auslesen auch ihren Wert behalten hat.

> __brkval wächst dann in 4(byte) schritten  wenn  malloc(1); ausgeführt
> wird .

Das ist OK.  Der minimal allozierbare Speicherblock ist 2 Bytes (weil
beim Freigeben da hinein der next-Zeiger in der freelist-Verkettung
passen muss), und 2 Bytes Overhead sind notwendig, um die Länge des
allozierten Blocks abzulegen.  free() muss diese Länge wissen, bekommt
sie aber nicht als Parameter mit.  Daher wird dieser Wert unmittelbar
vor dem Block abgelegt, den der Nutzer dann als Zeiger bekommt.

>> auch komisch :  nach rest ist brkval entweder BF92 oder FF92.
>
>> das highbyte ist nur immer anders ...
>
> Das Adresslatch deines Externspeichers wird wohl ein Problem
> haben.  Da brauchst du dich dann auch nicht wundern, warum das
> malloc() nicht das tut, was es soll.  Das verlässt sich natürlich
> schon drauf, dass eine einmal gesetzte Variable beim nächsten
> Auslesen auch ihren Wert behalten hat.
>



wenn ich  den controller resete  dann ist das HIGH-byte des __bekval 
immer anders also die beiden werte oben .

bei prgrammablauf  verhält es sich dann korrekt und wird nach einigen 
malloc´s größer .

das komische ist nur der startwert  trotz des gleichen programms anders 
ist und der wert nicht zwischen heap_start und heap_end liegt .

Direkt nach einem Reset (also am Anfang von main(), vor dem
ersten malloc()) muss __brkval gleich 0 sein.  Wenn es das
nicht ist, dann debugge bitte erstmal deinen externen RAM.

das mach ich mal !...

hat denn nun jemand mal ne ahnung ob __brkval relativ zu heap_start 
angibt oder absolut im speicher ??

Re To wrote:

> hat denn nun jemand mal ne ahnung ob __brkval relativ zu heap_start
> angibt oder absolut im speicher ??

Das kannst du dir auch im Sourcecode angucken...  Da drin steht
die erste Speicheradresse oberhalb des Heaps.  Freigegebener Speicher
wird aber nicht wieder ,,zurückgegeben'', sondern in der freelist
verwaltet.