www.mikrocontroller.net

Forum: Compiler & IDEs Wie viel RAM verbraucht malloc()? (ARM)


Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann mir bitte jemand sagen, wie viel RAM malloc() aus der stdlib von 
WinARM für die Listen verbraucht? Ich habe das Problem, dass mein 
Controller immer abstürzt, weil anscheinend nicht genur RAM vorhanden 
ist. Wenn ich malloc weglasse und ein statisches Array bilde, ist das 
Problem weg. Auf Dauer gefällt mir diese 'Lösung' allerding nicht, weil 
es ein Sonderfall ist, dass ich den Speicherverbrauch kenne. Braucht es 
wirklich so viel RAM, um die Listen von malloc zu verwalten?

MfG Mark

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem kann verschiedene Ursachen haben.

Angefangen von einer unpassenden Definition des HEAP z.B. zu 
grossen/kleinen im Linkercontrolscript, über ein nicht passendes _sbrk_r 
in syscall.c als Supportfunktion für malloc() z.B. ohne Grössenabfrage, 
bis zu einem unpassenden Userprogramm z.B. einem reentranten 
Programmverlauf bei nicht reentrantem _sbrk_r.

Autor: Bobby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu jedem malloc() gehört auch ein free(),
sonst ist der Speicher irgendwann voll.

Ist eigentlich banal, daher entschuldige, wenn du das schon wustest.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und nicht zu vergessen:
Fehler im Programm (der häufigste Fall)

Wieviel Speicher malloc() für seine Buchhaltung
abzwackt, hängt vom malloc() ab. Aber meist bewegt
sich das in der Größenordnung eines Pointers pro
Allokierung.

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

danke für die Hilfe.

@stefb
Ich bin in dem Gebiet eher Anfänger, deshalb verstehe ich nicht ganz was 
Du meinst. Könnstest Du bitte erklären, was _sbrk_r ist? Das 
Linkerscript hab ich von einem Projekt für den gleichen 
Controller(LPC2138) aus 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm... 
übernommen, daher denke ich, dass es nicht das Problem sein wird.

@Bobby
Das ist mir schon klar. Aber der Speicher wird ständig gebraucht, sodass 
in meinem Fall kein free() benötigt wird.

@kbuchegg
>Fehler im Programm (der häufigste Fall)
In meinem Programm taucht malloc() ein einziges mal auf, wobei genau 
64bytes allociert werden (sollten). Wenn ich es weglasse und stattdessen 
ein statisches Array definiere ist das Problem weg. Daher vermute ich, 
dass es eher an malloc() liegt, welches übrigens keine 0 zurückgibt.


MfG Mark

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Prediger wrote:

>>Fehler im Programm (der häufigste Fall)
> In meinem Programm taucht malloc() ein einziges mal auf, wobei genau
> 64bytes allociert werden (sollten). Wenn ich es weglasse und stattdessen
> ein statisches Array definiere ist das Problem weg.

Das heist noch lange nicht, das da nicht trotzdem irgendwo
ein Fehler drinnen ist.

> Daher vermute ich,
> dass es eher an malloc() liegt, welches übrigens keine 0 zurückgibt.

Das glauben sie immer:
Der Compiler hat Fehler, die Runtime Bibliothek hat Fehler, etc.
Natürlich sind all diese Dinge auch von Menschen geschrieben
und die Wahrscheinlichkeit, dass da kein Fehler drinnen ist,
ist nicht 0.
Aber die Wahrscheinlichkeit, dass du einen Fehler eingebaut hast
und nicht der Compiler oder die Library Schuld ist, liegt bei
weit über 99%

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AFAIR hat malloc bei mir mit den Beispielen von Martin Thomas 
funktioniert.
Abgesehen davon ist es doch irgendwo zwischen unlogisch und unnötig, ein 
statisches array mit malloc zu allokieren. Also, was soll der Umstand?

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ist mir schon klar. Aber der Speicher wird ständig gebraucht, sodass
>in meinem Fall kein free() benötigt wird.
wenn der speicher ohnehin dauernd gebraucht wird, welchen sinn hat dann 
malloc?

gruss
gerhard

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gerhard wrote:

> wenn der speicher ohnehin dauernd gebraucht wird, welchen sinn hat dann
> malloc?

Er schrob doch, dass das später mal eine variable Zahl sein soll,
also offenbar erst einmal nur für den Test 64 Bytes.  Damit hat
das schon Sinn.

Klar kann der Fehler trotzdem im Programm liegen.  Wenn du da 65
Bytes benutzt, obwohl nur 64 alloziert sind, werden sich die
Fehlerbilder stark unterscheiden je nachdem, ob die ursprüngliche
Allokation als statische/globale Variable, als lokale Variable
(auf dem Stack) oder via malloc() (im Heap) erfolgte.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> gerhard wrote:
>
>> wenn der speicher ohnehin dauernd gebraucht wird, welchen sinn hat dann
>> malloc?
>
> Er schrob doch, dass das später mal eine variable Zahl sein soll,
> also offenbar erst einmal nur für den Test 64 Bytes.  Damit hat
> das schon Sinn.

Das dachte ich zunächst auch. Aber: Das macht nicht wirklich
Sinn, vor allem dann nicht wenn es die einzige dynamische
Allokierung im Programm ist.
Was soll denn passieren, wenn die variable Zahl zu gross ist?
Ich wette mal, dass da keine vernünftige Behandlung erfolgt,
falls malloc eine NULL zurückliefert.
Aber selbst wenn die variable Anzahl in den Speicher passt:
Allokiere das alles statisch und benutzt einen Teil davon
einfach nicht. Läuft auf dasselbe hinaus und ist simpler.

>
> Klar kann der Fehler trotzdem im Programm liegen.  Wenn du da 65
> Bytes benutzt, obwohl nur 64 alloziert sind, werden sich die
> Fehlerbilder stark unterscheiden je nachdem, ob die ursprüngliche
> Allokation als statische/globale Variable, als lokale Variable
> (auf dem Stack) oder via malloc() (im Heap) erfolgte.

Yep.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Prediger wrote:
> @stefb
> Ich bin in dem Gebiet eher Anfänger, deshalb verstehe ich nicht ganz was
> Du meinst. Könnstest Du bitte erklären, was _sbrk_r ist? Das
> Linkerscript hab ich von einem Projekt für den gleichen
> Controller(LPC2138) aus
> http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...
> übernommen, daher denke ich, dass es nicht das Problem sein wird.

_sbrk_r ist die Funktion, die malloc benutzt, um Speicherplatz vom Heap 
zu bekommen. Diese Funktion ist prozessorabhängig und eine der sog. 
Syscalls (Source oft in syscall.c). Sie muss bei einigen µC selbst 
geschrieben werden und bei anderen µC hat das jemand bereits erledigt. 
Die Funktion selbst benötigt Infos vom Linkercontrollscript, wo der Heap 
beginnt und endet (z.B. SRAM-Bereich zwischen Variablen und Stack).

Durch deine Zusatzinfo denke ich, das _sbrk_r ist das eher nicht das 
Problem.

Kannst du ein kurzes Projekt anlegen und anhängen, mit dem sich der 
Fehler reproduzieren lässt?


Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

kbuchegg wrote:
>Das dachte ich zunächst auch. Aber: Das macht nicht wirklich
>Sinn, vor allem dann nicht wenn es die einzige dynamische
>Allokierung im Programm ist.

Es ist nur in diesem Fall die einzige. später wird es vorkommen, dass es 
nicht mehr die einzige ist.

>Was soll denn passieren, wenn die variable Zahl zu gross ist?
>Ich wette mal, dass da keine vernünftige Behandlung erfolgt,
>falls malloc eine NULL zurückliefert.

Sollte malloc() tatsächlig NULL liefern, wird das LCD blau, in der Mitte 
kommt der Text "Runtimeerror 2" und das Programm bleibt in einer 
Endlosschleife hängen.

>Aber selbst wenn die variable Anzahl in den Speicher passt:
>Allokiere das alles statisch und benutzt einen Teil davon
>einfach nicht.
Gerade dafür benutze ich ja malloc(), damit wirklich nur der Speihcer 
reserviert wird, der benötigt wird.

...
Ich hab eben mein Programm etwas umgeschrieben, sodass ein Objekt auf 
dem LCD an einer anderen Stelle dargestellt wird. Komischerweise ist das 
Problem weg. Wird wohl doch ein Programmfehler sein.

Danke für Eure Hilfe

MfG Mark

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Prediger wrote:
> Hallo.
>
> kbuchegg wrote:
>>Das dachte ich zunächst auch. Aber: Das macht nicht wirklich
>>Sinn, vor allem dann nicht wenn es die einzige dynamische
>>Allokierung im Programm ist.
>
> Es ist nur in diesem Fall die einzige. später wird es vorkommen, dass es
> nicht mehr die einzige ist.

OK.
Das wusste ich nicht.
Bis jetzt war die Information die, dass es nur einen malloc gibt.

>>Aber selbst wenn die variable Anzahl in den Speicher passt:
>>Allokiere das alles statisch und benutzt einen Teil davon
>>einfach nicht.
> Gerade dafür benutze ich ja malloc(), damit wirklich nur der Speihcer
> reserviert wird, der benötigt wird.

Das ging noch von der Annahme aus, dass es nur einen malloc gäbe.
Wenn es tatsächlich nur einen gibt, ist es sinnlos nur den
benötigten Speicher zu reservieren. Man kriegt von Atmel
kein Geld für nicht benutzten Speicher zurück :-)

Da sich aber die Annahme als falsch heruasgestellt hat,
ist damit auch die Prämisse gefallen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.