Der aktuelle Prozess verwendet alle Handles EOSError

[JYPDWhite]

Hi ihr,

ich suche seit knapp 3 Tagen einen Fehler bei uns in einem Programm. Er äußert sich darin dass das umschalten von TabSheets nicht mehr funktioniert und ich von Delphi die Exception bekomme:

Zitat:

... Exception der Klasse EOSError mit der Meldung 'Systemfehler. Code: 1158.
Der aktuelle Prozess verwendet alle Handles der zulässigen Höchstanzahl für Window Managerobjekte' aufgetreten.

Der Stacktrace sieht zu dem Zeitpunkt so aus:

Zitat:

:758cc42d KERNELBASE.RaiseException + 0x58
System.SysUtils.RaiseLastOSError(???)
System.SysUtils.RaiseLastOSError
Vcl.Controls.TWinControl.CreateWnd
Vcl.StdCtrls.TCustomCheckBox.CreateWnd
Vcl.Controls.TWinControl.CreateHandle
Vcl.Controls.TWinControl.UpdateShowing
Vcl.Controls.TWinControl.UpdateShowing
Vcl.Controls.TWinControl.UpdateShowing
Vcl.Controls.TWinControl.UpdateShowing
Vcl.Controls.TWinControl.UpdateShowing
Vcl.Controls.TWinControl.UpdateControlState
Vcl.Controls.TWinControl.CMVisibleChanged(???)
Vcl.Controls.TControl.WndProc((45067, 1, 0, 0, 1, 0, (), 0, 0, (), 0, 0, ()))
Vcl.Controls.TWinControl.WndProc((45067, 1, 0, 0, 1, 0, (), 0, 0, (), 0, 0, ()))
Vcl.Controls.TControl.Perform(???,???,0)
Vcl.Controls.TControl.SetVisible(True)
Vcl.ComCtrls.TPageControl.ChangeActivePage($18F044 )
Vcl.ComCtrls.TPageControl.SetActivePage($FFAA3900)
Vcl.ComCtrls.TPageControl.UpdateActivePage
Vcl.ComCtrls.TPageControl.Change
Vcl.ComCtrls.TCustomTabControl.CNNotify(???)
Vcl.Controls.TControl.WndProc((48206, 149608, 1636636, 0, 18536, 2, (), 63772, 24, (), 0, 0, ()))
Vcl.Controls.TWinControl.WndProc((48206, 149608, 1636636, 0, 18536, 2, (), 63772, 24, (), 0, 0, ()))
Vcl.Controls.TControl.Perform(???,???,1636636)
Vcl.Controls.DoControlMsg(???,(kein Wert))
Vcl.Controls.TWinControl.WMNotify((78, (), 149608, $18F91C, 0))
Vcl.Controls.TControl.WndProc((78, 149608, 1636636, 0, 18536, 2, (), 63772, 24, (), 0, 0, ()))
Vcl.Controls.TWinControl.WndProc((78, 149608, 1636636, 0, 18536, 2, (), 63772, 24, (), 0, 0, ()))
Vcl.Controls.TWinControl.MainWndProc(???)
System.Classes.StdWndProc(149628,78,149608,1636636 )
Vcl.Controls.TWinControl.DefaultHandler(???)
:004fbeab TControl.SetVisible + $2B

Und so siehts zu der Zeit im Taskmanager aus:
(Siehe Anhang)




Jemand irgendeine Idee? FastMM4 ist schon scharf gestellt und findet keine Lecks usw. Wobei ich dem seit heute eh nicht mehr traue.


Das ganze passiert nachdem ein Datensatz geladen wird. Das Problem dabei ist dass es ein "organisch" gewachsenes Programm ist ... sprich da ordentlich Code dahinter ist der mal überarbeitet gehört.

[Bernhard Geyer]

Das werden GDI-Handels, keine "normalen" Datei/...-Handels sein.
Und wenn FastMM nix findet dann sind diese GDI-Handels nicht "verloren" sondern "nur" nicht mehr sichtbar.
D.h. du legst irgendwo ein Element (mit GDI-Handle) an, vergisst es, aber das Formular hält sich das noch als Referenz.
Alternativ wird einfach irgendwo beim Zeichnen vergessen das Handle frei zu geben. So was kann FastMM nicht finden. Evtl. würde man das mit AQTime finden.

[JYPDWhite]

Kann man irgendwo die Anzahl von GDI-Handles auslesen?

[hoika]

Hallo,

viell. hilft das hier?

http://blogs.msdn.com/b/dsui_team/ar...urce-leak.aspx

Und natürlich
http://technet.microsoft.com/de-de/s.../bb896653.aspx
Dort unter Select Columns/ Process Memory/ GID Objects

Heiko

[Der schöne Günther]

Ist das nicht schon, was man im Taskmanager sich als "GDI-Objekte" anzeigen lassen kann?

[JYPDWhite]

@hoika
Dank dir für den Link dass man die GDI-Handles im Taskmanager anzeigen kann wusste ich noch nicht

Ok das Programm hat zum Zeitpunkt der Exceptions 1634 GDI-Handles offen. Jedoch hat es wärend der Datensatz geladen wird über 100 mehr. Und laut dem Link sollte ich da auch noch weit von irgendwelchen Grenzen entfernt sein.

Den Rest des Links arbeite ich dann morgen bzw im Laufe der Woche durch. Dank dir erstmla

Edit: Ok also ne GDI-Handlegrenze sollte es nicht sein. BDS.exe hat momentan kanp 4,5k Handles ...

[himitsu]

Dann sind es wohl keine GDI-Handles (zumindestens nicht in deinem Programm, oder es gab vor dem Knall mal mehr), aber es gibt ja noch massig andere Handles (Dateien, Speicher, Ports usw.).
Aber da es in CreateWnd knallt, liegt der Verdacht nunmal nah, daß es sich um GDI-Handles handeln sollte.
Eventuell geht es auch um ATOMs.

Diese Handles sollten aber global für ganz Windows gelten.
Gibt es denn andere Programme mit vielen Handles?

http://msdn.microsoft.com/de-de/libr.../ms724291.aspx
GDI-Handles sind ein WORD groß und der erste Eintrag wird nicht verwendet (die 0),
was also maximal 65.535 mögliche Handles macht, innerhalb einer Session. (z.B. pro angemeldeten Benutzer)


Du könntest mal mit dem Process Explorer schauen, ob man etwas sieht.

Ach ja, FastMM kann natürlich erstmal nur den Speicher loggen/analysieren, welcher auch noch über ihn reserviert wurde.
Speicher, welchen man direkt bei Windows, oder in einem anderen Speichermanager reserviert, geht an dem ja praktisch vorbei.

[Luckie]

Generell kann man sagen, wenn man sich die Frage stellt: "Was ist der Maxdimalwert von XYZ", dann macht man was falsch. Weil in der Regel kommt man seltenst an die Grenze, wenn man es richtig macht.

Ich könnte mir vorstellen, dass du in einer Schleife GDI-Handles erzeugst, sie aber nicht wieder frei gibst. Und dann geht das in der Schleife ratz-fatz. Und du bist am Ende.

[JYPDWhite]

Die Idee mit dem Process Explorer war gut.
Da sieht man dass es nicht die GDI-Handles sind sondern die USER-Objects.
Ein Leak an Handles scheint es auch nicht zu sein. Denn wenn ich den Testdatensatz laden steigen die User-Objects auf knapp 9,8k an. Wenn ich dann im Programm auf Datei --> Neu gehen sinken die Werte wieder auf praktisch die selben Werte (vielleicht 300 Handles mehr) wie direkt nach dem Programmstart.
Das Problem scheint zu sein dass wir in dem Programm an mehreren Stellen eine Scrollbox haben und in diese kann man weitere Zeilen mit Eingaben einfügen indem man auf einen Button klickt.
Das habe ich gerade mal nachgestellt und von Hand dort hunderte Einträge hinzugefügt. Dabei steigen die User-Objects immer weiter an bis man dann irgendwann bei 10k ist und das Programm abstürzt.

Nun habe ich natürlich das Problem dass ich das Problem irgendwie beheben muss. Eine Idee die ich hätte wäre die Karteireiter die gerade nicht sichtbar sind auch nicht im Speicher zu halten (und damit ja auch keine Handles dafür zu brauchen) Jedoch kommt da zum tragen dass das Programm zum großen Teil kein Datenmodell hat bzw. die Werte direkt aus der Maske verwendet werden.