PureBoard

Hallo zusammen,

eine kurze Frage:
Sind unter Windows 10 (x64) mit PB5.62 (x86, Option Thread-safe ist aktiv) Probleme bekannt im Bezug auf AllocateMemory in Threads?

Ich habe hier eine Anwendung, die bei mehreren Usern (~14 Rechner) läuft und sporadisch Probleme bereitet.
Der Fehler trat zunächst über alle User hinweg zusammengezählt etwa 20 mal pro Woche auf.

Einmal habe ich es bei mir nachbilden können und den Fehler soweit eingekreist,
dass ein AllocateMemory(16777215) welches in einem Thread aufgerufen wird, fehlschlägt.

Um dieses Problem herum habe ich nun eine Schleife gebaut, wodurch die Speicherallokierung 25mal
im Abstand von 15ms wiederholt wird und erst dann abbricht. Hierdurch ist die Fehlerrate auf etwa 1-2mal pro Woche gesunken.

Dies ist aber nur ein Workaround und keine Lösung, darum hier die Frage..

Danke für alle Tipps..

------------------

PS: Der Thread ist/wird 5x simultan ausgeführt und bleibt/bleiben bis zum Programmende offen.
(Verarbeitung von Jobs, welche vom Hauptprogramm kommen.)

AllocateMemory in Threads sind kein problem.

Aber man muss überprüfen ob die Anforderung vom Speicher erfolgreich ist.
Denn wenn nicht genügend zusammenhängender Speicher verfügbar ist, schlägt die Funktion fehl und bekommst ein NULL Zeiger zurück.

Ja, so kenne ich das auch. Danke

Aber 16MB können doch heutzutage kein Problem mehr sein?
Es scheitert wie gesagt nur an dem AllocateMemory.

Die Überprüfung erfolgte vorher auch schon, nur ohne Schleife.

Gibt es noch andere Ursachen, für den Fehler?

Wenn ich das richtig verstanden habe, dann baust du einen Thread-Pool, also du hast 5 durchgehend laufende Threads.
Geht es wirklich darum immer wieder 16 MB zu allozieren, oder braucht jeder Thread diese 16 MB auch nur am Anfang einmal und nutzt das durchgehend? In letzterem Fall könntest du auch das Hauptprogramm einfach einen Speicherbereich von 5*16 MB am Stück allozieren lassen und dann jedem Thread seinen Offset dazu geben, damit er es nutzen kann.

Ansonsten hatte ich da auch noch nie Probleme und im Grunde gilt, was mk-soft schon gesagt hat. Rückgabewerte muss man natürlich immer prüfen. Falls meine Vermutung von oben nicht zutrifft: Wie häufig versuchst du denn Speicher zu allozieren?

Wenn eine Schreibanweisung vorher zB über einen reservierten Speicher hinausschreibt, wird der Memory-Heap zerstört.
Dadurch gibt es zunächst erst mal keine Fehlermeldung, wohl aber dann, wenn neuer Speicher angefordert wird: Du kannst mal mit dem Purifier gucken, ob du ein solches Überschreiben hast,

NicTheQuick hat geschrieben:Geht es wirklich darum immer wieder 16 MB zu allozieren, oder braucht jeder Thread diese 16 MB auch nur am Anfang einmal und nutzt das durchgehend?

Da hast du natürlich recht. Ich könnte den Code so umschreiben, dass jeder Thread
den Speicher nur einmal beim Start alloziert und ich die enthaltenen Daten dann im
nächsten Durchlauf mit FillMemory als ungültig markiere.

NicTheQuick hat geschrieben:Wie häufig versuchst du denn Speicher zu allozieren?

Das kann man sehr schwer vorhersagen.
Etwa alle 40ms einmal, kann aber auch nur einmal in der Stunde sein.

Die Grundidee dabei war, nicht unnötig Speicher zu belegen..

STARGÅTE hat geschrieben:Wenn eine Schreibanweisung vorher zB über einen reservierten Speicher hinausschreibt, wird der Memory-Heap zerstört.
...
Du kannst mal mit dem Purifier gucken, ob du ein solches Überschreiben hast,

Danke für die Info. Dies ist mir bereits bekannt und war auch meine erste Vermutung,
dass sich eine Schreiboperation selbstständig macht.

Eine IMA (d.h. Programmabsturz) trat nicht auf. Nur der Thread brach ab, da er keinen Speicher für die Datenverarbeitung zugewiesen bekam.

Die Software ist nun soweit geändert, dass der Alloc nur einmal beim Tread-Start erfolgt.
Mal sehen, wie es sich jetzt verhält. Ich werde berichten..

Was in diesem Thread glaube ich noch nicht erwähnt wurde ist die Möglichkeit eines Speicherlecks. Wenn Speicher nicht konsequent wieder freigegeben wird, dann ist er natürlich irgendwann alle. Du kannst Macros für AllocateMemory() und FreeMemory() verwenden um das zu überwachen.

#NULL hat geschrieben:Was in diesem Thread glaube ich noch nicht erwähnt wurde ist die Möglichkeit eines Speicherlecks. Wenn Speicher nicht konsequent wieder freigegeben wird, dann ist er natürlich irgendwann alle. Du kannst Macros für AllocateMemory() und FreeMemory() verwenden um das zu überwachen.

Das ist ebenfalls bekannt und wurde beachtet.

Ein paar Zeilen nach dem Alloc wird der Speicher wieder freigegeben.
Einen Vorab-Ausstieg gibt es dabei nicht, so dass FreeMemory nicht aufgerufen würde..

Aber Danke für den Hinweis.

PS: Aktuell ist es so, dass FreeMemory nun kurz vor dem Thread-Ende erst aufgerufen wird. KillThread gibt es nicht.