Hallo zusammen,

ich habe ein Tool geschrieben, welches auf Basis der Exif-Daten Grafikdateien so umbenennt, das auch Bilder unterschiedlicher Kameras zeitlich richtig sortiert dargestellt werden.

Jeder der nach einem Urlaub die Bilder verschiedener Kameras händeln muss, wird das Problem kennen.

Um die Exif-Daten auszulesen, bin ich auf die Library "ImageStone" gestoßen.
In dieser wird beim Laden der Grafikdatei dynamisch Speicher mit "malloc" angefordert.

Bei einem Testlauf ist mir aufgefallen, das malloc nur funktioniert, wenn die Grafikdatei kleiner als 32MB ist. Sollte eigentlich reichen, aber bei Panoramas wird diese Grenze schon mal gerne gesprengt.

Kennt jemand dieses Phänomen?
Bisher bin ich noch auf keine Lösung gestoßen.
Kann mir vielleicht hier jemand helfen.

Danke schon einmal im Vorraus.

P.S.: Das Tool muss auf WinXp (x32) laufen.

Hi.

Also 32 MiB sind lachhaft. Die Obergrenze bei einem 32bit Windows-System liegt bei 2GB Speicher der von einem Prozess verwendet werden kann. Ist der Speicher evtl. bereits erschöpft?

Wie sieht der Code aus?

Gruß

Hallo,

hab da wohl nicht genau genug geschrieben, was ich im Debugger sehe und die Zahlen am Ende auch nicht mehr mit Adlersaugen betrachtet.

Daher jetzt richtig:
Die Grafikdatei (jpg) ist 38MB groß.
Malloc soll 631321860Byte allocieren. Und das gleich zweimal. macht ca 1,3GB in Summe.

Die Library ist leider nicht von mir und mir reichts wenn die großen Panos nicht betrachtet werden.
Das Problem würde ich dennoch gern verstehn.

Ja schau dir dochmal deinen Arbeitsspeicher an, wie sollen 1.3 GB alloiziert werden, ewnn die nicht mehr zur verfügung stehen?.
Bei mir läuft Win XP mit allen Hintergrundprogrammen auf 500-800MB auslastung des Arbeitsspeicher.

Zitat von 3Cyb3r

Ja schau dir dochmal deinen Arbeitsspeicher an, wie sollen 1.3 GB alloiziert werden, ewnn die nicht mehr zur verfügung stehen?.
Bei mir läuft Win XP mit allen Hintergrundprogrammen auf 500-800MB auslastung des Arbeitsspeicher.

Schonmal etwas von virtuellem Speicher gehört?

1.3 GB können durchaus von einem Prozess insgesamt alloziert werden, allerdings nicht unbedingt "am Stück".

Code c:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <stdio.h> #include <stdlib.h>   int main(int argc, char *argv[]) {     void* m = malloc(1.4 * 1024 * 1024 * 1024);       if (m != NULL) {         puts("yes");         free(m);     } else {         puts("no");     }     getchar(); }

Hier werden 1.4 GiB Speicher alloziert. Im Task Manager steht ein Wert von 1.469.948KB.

Um die EXIF Daten auszulesen mußt du aber auch nicht die ganze Datei dekodiert in den Speicher laden. Nimm eine andere Bibliothek oder probier's mal mit memory-mapped files.

Gruß

Hallo,
bin mir nicht sicher, ob ich das jetzt richtig rum schreibe, aber gibts da nicht einen Unterschied zwischen Stack und Heap? Wird der Speicher nicht anders verbaut, wenn bereits zum Compile Zeitpunkt bekannt ist, wieviel benötigt wird?

Ich werd den Ansatz aber mal nutzen und etwas testen. Vielleicht finde ich ja noch was.


Gruß

So nach einigen Tests liegen follgende Ergebnisse vor:

Im Construktor des MFC Dialoges kann ich ca 650800000 Byte 2x anlegen.
Mitten im Programm nur noch 2x 526100000 Byte.

Die benötigten 631321860 Byte sind also nicht mehr an gewünschter Stelle mögich.

Daher meine Frage:
Gibt es die Möglichkeit den freien Speicher zu ermitteln? Evt. durch eine try & catch Anwendung?

Zitat von Salama

bin mir nicht sicher, ob ich das jetzt richtig rum schreibe, aber gibts da nicht einen Unterschied zwischen Stack und Heap? Wird der Speicher nicht anders verbaut, wenn bereits zum Compile Zeitpunkt bekannt ist, wieviel benötigt wird?

Mit malloc allozierter Speicher wird immer auf dem Heap angelegt. Automatische Variablen (z.B. statische Arrays) werden auf dem Stack angelegt.

Zitat von Salama

So nach einigen Tests liegen follgende Ergebnisse vor:

Im Construktor des MFC Dialoges kann ich ca 650800000 Byte 2x anlegen.
Mitten im Programm nur noch 2x 526100000 Byte.

Die benötigten 631321860 Byte sind also nicht mehr an gewünschter Stelle mögich.

Daher meine Frage:
Gibt es die Möglichkeit den freien Speicher zu ermitteln? Evt. durch eine try & catch Anwendung?

Ja, das geht. Aber wozu soll das gut sein? Wenn nicht mehr soviel Speicher frei ist wie du brauchen würdest, dann nützt dir doch auch die Information nichts wieviel Speicher jetzt noch frei ist. Oder was willst du damit erreichen?

Gruß

Hallo,
die Info wäre insofern interessant um, die entsprechenden Library Funktionen zu vermeiden. Zur not reichen auch die "Erstellt am" Daten einer Datei. Das wäre zumindest die Quick & Dirty Version ohne die Library zu ändern

Nicht das das Tool täglich verwendet werden würde, aber abstürzen sollte es doch nicht.

Werd mal schauen was ich in der Lib noch machen kann... letztlich muss man ja davon ausgehen, das Speicher mal nicht angefordert werden kann.

Schönen Abend

Zitat von Salama

Hallo,
die Info wäre insofern interessant um, die entsprechenden Library Funktionen zu vermeiden. Zur not reichen auch die "Erstellt am" Daten einer Datei. Das wäre zumindest die Quick & Dirty Version ohne die Library zu ändern

Nicht das das Tool täglich verwendet werden würde, aber abstürzen sollte es doch nicht.

Werd mal schauen was ich in der Lib noch machen kann... letztlich muss man ja davon ausgehen, das Speicher mal nicht angefordert werden kann.

Du hast noch nicht genau gesagt wo das Problem auftritt. In der ImageStone Bibliothek direkt?

Da es sich bei der Bibliothek um C++ handelt, wird doch hoffentlich statt malloc() der new bzw. new[] Operator verwendet, oder?

Dann wird eine std::bad_alloc Ausnahme geworfen die man fangen und behandeln kann. (wenn man einen ordentlichen C++ Compiler verwendet)

Auch bei malloc kann man prüfen ob Speicher alloziert werden konnte.

Gruß

Guten Morgen,

es wird tatsächlich "malloc" parallel zu Klassen verwendet.
Um folgende Funktion geht es:

Code :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

inline BYTE* FCOXOHelper::ZeroMalloc (int nBytes) { #ifdef WIN32 int error=0;       // BoundChecker can's check the memory alloc by <VirtualAlloc>     #ifdef _DEBUG               BYTE   * pByte = (BYTE*)malloc (nBytes) ;         memset (pByte, 0, nBytes) ;                 return pByte ;     #else         return (BYTE*)VirtualAlloc (NULL, nBytes, MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE) ;     #endif   #else           BYTE   * pByte = (BYTE*)malloc (nBytes) ;         memset (pByte, 0, nBytes) ;         return pByte ;   #endif }

Wie gesagt ich kann die Problematik außerhalb der Lib nachvolllziehn. Da in Sachen laden von Grafiken kein Handling von großen Grafiken vorgesehn ist, scheint auch eine entsprechende Bearbeitung nicht implementiert.

Gruß

Hi.

Dann ändere doch einfach den Code der ZeroMalloc Funktion so, dass eine std::bad_alloc Ausnahme geworfen wird. Die kannst du ja dann fangen und behandeln.

Gruß