AllocateMemory in Thread
AllocateMemory in Thread
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.)
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.)
Never change a running system - Never run a changed system!
(PB 6.03 LTS [x86])
(PB 6.03 LTS [x86])
Re: AllocateMemory in Thread
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.
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.
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Re: AllocateMemory in Thread
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?
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?
Never change a running system - Never run a changed system!
(PB 6.03 LTS [x86])
(PB 6.03 LTS [x86])
- NicTheQuick
- Ein Admin
- Beiträge: 8679
- Registriert: 29.08.2004 20:20
- Computerausstattung: Ryzen 7 5800X, 32 GB DDR4-3200
Ubuntu 22.04.3 LTS
GeForce RTX 3080 Ti - Wohnort: Saarbrücken
- Kontaktdaten:
Re: AllocateMemory in Thread
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?
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?
Re: AllocateMemory in Thread
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,
Dadurch gibt es zunächst erst mal keine Fehlermeldung, wohl aber dann, wenn neuer Speicher angefordert wird:
Code: Alles auswählen
*Buffer1 = AllocateMemory(16)
Debug "Allocate"
RandomData(*Buffer1, 32)
Debug "Write overflow"
*Buffer2 = AllocateMemory(16) ;- Absturz
Debug "Next Allocate"
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Re: AllocateMemory in Thread
Da hast du natürlich recht. Ich könnte den Code so umschreiben, dass jeder ThreadNicTheQuick 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?
den Speicher nur einmal beim Start alloziert und ich die enthaltenen Daten dann im
nächsten Durchlauf mit FillMemory als ungültig markiere.
Das kann man sehr schwer vorhersagen.NicTheQuick hat geschrieben:Wie häufig versuchst du denn Speicher zu allozieren?
Etwa alle 40ms einmal, kann aber auch nur einmal in der Stunde sein.
Die Grundidee dabei war, nicht unnötig Speicher zu belegen..
Never change a running system - Never run a changed system!
(PB 6.03 LTS [x86])
(PB 6.03 LTS [x86])
Re: AllocateMemory in Thread
Danke für die Info. Dies ist mir bereits bekannt und war auch meine erste Vermutung,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,
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.
Never change a running system - Never run a changed system!
(PB 6.03 LTS [x86])
(PB 6.03 LTS [x86])
Re: AllocateMemory in Thread
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..
Mal sehen, wie es sich jetzt verhält. Ich werde berichten..
Never change a running system - Never run a changed system!
(PB 6.03 LTS [x86])
(PB 6.03 LTS [x86])
Re: AllocateMemory in Thread
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.
Re: AllocateMemory in Thread
Das ist ebenfalls bekannt und wurde beachtet.#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.
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.
Never change a running system - Never run a changed system!
(PB 6.03 LTS [x86])
(PB 6.03 LTS [x86])