Ich habe mit Delphi6 ein kleines Jukeboxprogramm mir playlisten programmiert. Das ganze läuft auch wunderbar, nur wenn ich es 5-6std laufen lasse, bekomme ich jedes mal die fehlermeldung "MMSystem264 für diesen vorgang steht nicht genügend Arbeitsspeicher zur Verfügung" Ich habe schon alle möglichen Debugger wie code watcher oder Memproof durchlaufen lassen, aber es werden keine Speicher leaks erkannt...?! Woran kann der fehler denn noch liegen? Danke und MFG Manuel
Programmieren - alles kontrollieren 4.941 Themen, 20.715 Beiträge
Artikel aus der c't:
Windows-Programme, die sich nicht ordnungsgemäß beenden, belegen dauerhaft wertvolle Systemressourcen und können den Anwender im schlimmsten Fall zu einem Neustart zwingen.
Als erste Maschine begann Thor zu schwächeln. Mitte Februar wurde der funkelnagelneue Pentium-Vier-Kraftprotz mit seinen 256 MByte RAM immer lahmer. Bald darauf folgten ihm weitere Rechner im gleichen Stuttgarter Software-Labor. Der Fall schien klar: Es musste eine Infektion mit Computer-Viren sein. Doch keines der üblichen Antivirenprogramme schlug Alarm. Auch Hardware-Defekte oder Netzprobleme schieden als Ursache aus.
Es zeigte sich: Auf den befallenen Maschinen waren verdeckt zahlreiche Prozesse aktiv, die Speicherplatz belegten und etwa im Falle Thor nur noch kümmerliche 17 MByte RAM übrig gelassen hatten. Die Liste der aktiven Prozesse in den Windows-XP-Systeminformationen verriet letztendlich, dass die Underground-Tasks hausgemacht waren: In den Computern arbeiteten außer Kontrolle geratene Programmrelikte, `Zombies´. Offensichtlich hatte ein Programm sie ins Leben gerufen, das gerade im Labor entwickelt wurde.
Nun begann eine mehrtägige detektivische Kleinarbeit. Aus dem Programmprojekt wurde ein Codeteil nach dem anderen entfernt. Zuletzt blieb eine Art Leerprogramm `Zombie-Test´ übrig. Damit war der Nachweis erbracht, dass die Ursache im eingesetzten Programm-Entwicklungssystem zu suchen ist, in Borlands Delphi 6. Es zeigte sich, dass mit diesem Entwicklungssystem erzeugte Programme immer dann Zombies hinterlassen, wenn sie eine DLL statisch einbinden, die wiederum eine der Qt-Units aus der neuen Cross-Platform-Klassenbibliothek CLX verwendet.
Die deutsche Borland-Tochtergesellschaft konnte oder wollte bislang lediglich die Existenz des Phänomens bestätigen und einen Hinweis schicken, der zeigt, wie man um die gefährliche Konstellation herumprogrammieren kann: Man solle eben in DLLs keine der Qt-Units benutzen, sondern deren Funktionen nur aus dem eigentlichen Programm heraus aufrufen.
Abhilfe
Seriöse Entwickler mögen das Zombie-Phänomen als lästige Nachlässigkeit empfinden. In der Hand von Zeitgenossen, deren Lieblingsbeschäftigung das Programmieren von Viren und anderer Malware ist, stellt es jedoch eine neue Angriffsmöglichkeit dar. Immerhin: Im Unterschied zu Computerviren verbreiten sich Zombies nicht aktiv und richten auch nicht schlagartig Schaden an, sondern schädigen Rechner erst bei massivem Auftreten durch allmähliche Auszehrung. Wenn ein Nutzprogramm, das Zombies erzeugt, häufig gestartet und beendet wird, dann sammeln sich die Zombies im System an und zwingen es letztendlich in die Knie. Erst beim Herunterfahren des Rechners sterben die versteckten `Untoten´ wirklich.
Fachleute fürchten, dass Zombies in nächster Zeit zu einer ernsthaften Gefahr für PCs werden könnten: Der Stuttgarter Experte für Computeranwendungen in Sicherheitsbehörden, Kriminalhauptkommissar Rainer Eppler, beispielsweise empfiehlt den Herstellern von Abwehrprogrammen gegen Sabotage-Software dringlich, sich rechtzeitig vorsorglich auf die Erkennung und Bekämpfung von Zombies vorzubereiten.
Ob der R