"Speicher voll" bei Fenster öffnen
-
Moin,
habe hier grad eine Tierverwaltungs-Software vorliegen, bei der ein Kunde auf die dreiste Idee kommt, statt der üblichen 100-200 gleich mal 2500 Tiere zu verwalten.
Aus irgendeinem Grunde kommt es beim öffnen von Futterkurven(Canvas Gezeichne) und Tiereigenschaftsfenstern(Neuerzeugung eines Fensters mit ein paar mehr Eingabefeldern) nun des öfteren zu der Warnmeldung "Speicher voll" und kein Fenster öffnet sich.
Ist nicht wirklich ein Speicherleck, da es wohl auch sofort nach Neustart passiert.Speicherverbauch der Anwendung sind auch nur ca 20 MB und eigentlich müsste doch auch auf der Festplatte ausgelagert werden, daher kann ich das nicht wirklich nachvollziehen.
Version ist Borland C++ Builder 6 Prof.
Stack/Heapsize etc ist alles hochgedreht ohne viel zu bewirken.Kennt jemand das Problem vielleicht oder zumindest ein paar Tool, womit man das besser analysieren könnte?
Dreh hier langsam durch =[
-
Konsultiere doch mal den Debugger. Irgendwo eine Endlosrekursion?
-
Endlosrekursion ist leider auch nicht drin, es wird tatsächlich nur ein Fenster versucht zu erzeugen und sofort kommt die "Speicher voll" Meldung und nach wegklicken läuft das Programm normal weiter.
Lässt sich auch schwer debuggen, da der Fehler nur beim Kunden auftritt(und der in der Türkei ist Öö).
Im Hintergrund läuft noch die Kommunikation mit 8 USB-COM Ports, da habe ich noch die dumpfe Vermutung, die Treiber machen irgendwelchen Müll, aber wirklich überprüfen wüsste ich auch nicht wie.
-
dreaddy schrieb:
Endlosrekursion ist leider auch nicht drin, es wird tatsächlich nur ein Fenster versucht zu erzeugen und sofort kommt die "Speicher voll" Meldung und nach wegklicken läuft das Programm normal weiter.
Um den Verursacher zu finden, könntest du, wie hier gezeigt, die Exception zentral behandeln, die Adresse, von wo die Exception ausgelöst wurde (an die kommst du mit
ExceptAddr()
), loggen, mit VirtualQuery() das zugehörige Modul und dessen Basisadresse finden, dann demselben Build bei dir im Debugger starten und nachsehen, was am entsprechenden Offset im entsprechenden Modul für Code liegt.Etwas einfacher wird das Ganze, wenn du ein Tool wie madExcept oder JclDebug nimmst, um gleich den ganzen Call-Stack nachzuverfolgen.
dreaddy schrieb:
Lässt sich auch schwer debuggen, da der Fehler nur beim Kunden auftritt(und der in der Türkei ist Öö).
Im Zweifelsfalle geht so etwas mit dem Remote-Debugger.