std::bad_alloc mit QList<QByteArray>

[solarix]

Wenn die Widgets (allgemein: QObjects) in einer Objekthierarchie stecken, also einen parent haben, musst du das Widget dynamisch allokieren, sonst gibts trouble mit double-free (einmal über die QObject-Hierarchie, das andere mal wenn das Objekt aus dem Scope läuft).

Nur wenn der Parent vor dem (Child-)Widget zerstört wird..

das Problem liegt allerdings darin, dass auch wenn ich es durch häufiges "starten" endlich zum laufen kriege, es einwandfrei funktioniert.

Ich glaube auch nicht, dass hier der Speicher ausgeht. Ich vermute eher, dass (wie beim Ursprungsposter) eine Pointergeschichte falsch läuft und nur die Folgefehler beobachtet werden. In diesem Fall hilft der Debugger möglicherweise nicht weiter (weil das Programm nicht dort crashd, wo der Fehler verursacht wurde) sondern allenfalls ein guter Profiler wie z.B. "valgrind" unter Linux.

Falls du den Fehler runterbrechen könntest (z.B. in ein einziges main.cpp) würde das uns helfen..

hth..

[EDIT]
Ach ja: wenn deine Software ein Pointerproblem hat, hat sie dies auf jeder Plattform. Nur sind die Auswirkungen auf jeder Plattform etwas unterschiedlich. Das bedeutet aber auch, dass du z.B. "valgrind" nicht unbedingt auf dem Target-System laufen lassen musst, sondern auch auf einem Entwicklerhost.. und für den Debugger brauchst du auch kein Eclipse: "gdb meinProgramm" und nach dem Crash "where" reicht vollkommen..

[Thrake]

hmmm... an Arrays habe ich aber kaum was und die, die ich habe, sind in meiner klasse drin und sollten auch nicht wieder deletet werden. und das ist nur einer von der größe von [2000][6].

Und wie viele Instanzen dieser Klasse erstellst du? Wie groß sind die Objekte in dem Array?

Ich erstelle genau eine Instanz der Klasse und es handelt sich hierbei um doubles.

Ich vermute mal, dass ein Debuger (über Eclipse z.b.) auf dem Atom-Board mir das Problem liefern würde, wo das problem sei, oder?

Ja, ein Debugger ist nie verkehrt. Sollte eigentlich das erste sein, das du bei einem Laufzeitproblem versuchst

Dann werde ich das mal versuchen.

Ich glaube auch nicht, dass hier der Speicher ausgeht. Ich vermute eher, dass (wie beim Ursprungsposter) eine Pointergeschichte falsch läuft und nur die Folgefehler beobachtet werden. In diesem Fall hilft der Debugger möglicherweise nicht weiter (weil das Programm nicht dort crashd, wo der Fehler verursacht wurde) sondern allenfalls ein guter Profiler wie z.B. "valgrind" unter Linux.

Falls du den Fehler runterbrechen könntest (z.B. in ein einziges main.cpp) würde das uns helfen..

Mein problem ist ja, dass ich nicht weiß, wo der Fehler ist, sonst hätte ich ihn auch schon wirklich längst gepostet

Ach ja: wenn deine Software ein Pointerproblem hat, hat sie dies auf jeder Plattform. Nur sind die Auswirkungen auf jeder Plattform etwas unterschiedlich. Das bedeutet aber auch, dass du z.B. "valgrind" nicht unbedingt auf dem Target-System laufen lassen musst, sondern auch auf einem Entwicklerhost.. und für den Debugger brauchst du auch kein Eclipse: "gdb meinProgramm" und nach dem Crash "where" reicht vollkommen..

Vielen Dank für die Infos.

[RHBaum]

Denke auch, ohne debugger kommst ned weiter !

Dein [2000][6] ist das fix, oder ist die groesse variable ?

2000*6*8 = 96 000 byte. Ich weiss nicht wie dein BS aussieht, aber 96k sollten eigentlich immer drinn sein. Also wenn das dein BS ned liefern kann, hasst du andere Probleme

Du erzeugst auch andere, kleinere arrays ? sind die dyn. groesse. Wenn ja, checken was die groessen anbelangt. Nen fehler in der berechnung der arraygroesse draengt sich hier foermlich auf.

mit (funktionierendem) debugger waer das ziemlich easy. exception zum ausstieg nutzen, in der aufrufliste schaun was im eigenen code machst, und da variableninhalte pruefen ...

Ciao ...

[Thrake]

okay, ich hab es mit dem Debugger versucht... vielen herzlichen dank solarix für den Tipp mit der Console und dem GDB.

Den Fehler habe ich endlich gefunden! Ich erstelle ein Objekt einer Klasse, die von QAbstractListModel vererbt, allerdings erhält sie sonst keine Werte (Konstruktur ist leer). Ein QListView sollte eben den Inhalt dieses Models wiedergeben und da war der Knackpunkt: Beim setzen des Models von QListView wurde vorher kein Pfad angegeben (also ich brauchte eine Liste von Dateien in einem bestimmten Ordner). Ich habe deswegen die Liste einfach irgendeinen pfad (gleich nach dem erstellen) angeben lassen und mein problem hat sich erledigt.

Ich vermute mal das ein paar Variablen nur initialisiert wurden, aber nie einem Wert zugeordnet wurden, sodass nur "müll" drinstand der oft relativ groß war. Das hat meinem Laptop mit 4GB RAM nicht so arg gestört, aber dem Atom-PC umso mehr. Gemerkt habe ich das natürlich nicht (wie schon franzf mir es an einem guten Beispiel erklärt hat), weil ich dem Wert relativ schnell eine neue Zuordnung mitgeben.

Vielen herzlichen dank franzf für deine ausgezeichnete Hilfe! Irgendwie kommen mir die Community hier kompetenter vor als im Nokia-Trolltech Forum