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
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.
Zu jedem malloc() gehört auch ein free(), sonst ist der Speicher irgendwann voll. Ist eigentlich banal, daher entschuldige, wenn du das schon wustest.
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.
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_projects/index.html ü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
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%
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?
>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
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.
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.
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_projects/index.html > ü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?
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.