Handle Problem in Printers.pas (letzter Leak-Thread ;)

[Assertor]

Hi,

in Abschluss meiner Trilogie hier der letzte Thread zur Suche nach einem Handle Leak:

Gegeben sei ein leeres Testproject unter Nutzung der Printers.pas (z.B. in D2006 oder D2009):

Delphi-Quellcode:

procedure TestPrinter;
var
  i: Integer;
begin
  for i := 1 to 100 do
  begin
    Printer.BeginDoc;
    Printer.EndDoc;
  end;
end;

Ergebnis bei mir: Nach jedem Ausführen von TestPrinter steigt die Anzahl der Handles im TaskManager um 100.

Kann hier jemand etwas Licht ins Dunkel bringen?

Gruß Assertor

[nahpets]

Hallo Assertor,

habe mir Deine Routine genommen, unter Delphi 7 kompiliert und ausgeführt. Betriebssystem ist XP SP2. Die Zahl der Handles bleibt unverändert, es ist kein Zuwachs zu beobachten.

[Assertor]

Zitat:

Zitat von nahpets

Hallo Assertor,

habe mir Deine Routine genommen, unter Delphi 7 kompiliert und ausgeführt. Betriebssystem ist XP SP2. Die Zahl der Handles bleibt unverändert, es ist kein Zuwachs zu beobachten.

Danke Stephan, das war es! Habe gerade mehrere Windows-Drucker ausprobiert: Es ist ein Leak von den Druckertreibern hier im Büro - also mal den Hersteller anschreiben. Die Vermutung hatte ich schon, wollte es aber nicht wahrhaben. Ist ja immer schnell gesagt: Liegt nicht an der eigenen Software, sondern an anderen - aber hierbei stimmt das.

Eine total unnötige Suche, fragt sich nur wie man solche Schlamperei am besten kompensiert... :roll:

Gruß Assertor

:dp:

Nachtrag: Komisch, der selbe Drucker(treiber) macht keine solchen Probleme mit Notepad oder OpenOffice :?:

[Assertor]

Hi,

ich stelle mir gerade in diesem Zusammenhang die Frage, ob sich ein solches Leak aktiv vermeiden lässt?

Da gerade bei billigen Druckern die Reaktion in Bezug auf Treiberupdates seitens der Hersteller gering ausfällt, wäre eine Idee generell den Druck etwas robuster zu machen. Soweit ich gelesen habe betrifft dies ja neben Brother Druckern auch manche HP Druckertreiber. Lenovo & Co hatte auch schon Probleme mit Handle Leaks. Indirekt somit auch einige Delphi Reportengines - hier findet man auch einiges über Leaks die nicht nachvollziehbar sind.

Ich habe gerade mittels dem Handle Tools vom SysInternals Pack das Handle zumindest einwandfrei identifizieren können:

Zitat:

Section \\Sessions\1\BaseNamedObjects\17e25cPORT

Das ganze dann im proportionalen Verhältnis zur Anzahl der Druckaufträge. Statt .EndDoc geht auch .Abort - das Leaken bleibt.

Hat jemand noch eine Idee dazu?

Gruß Assertor

[Uwe Raabe]

Probier doch mal dies:

Delphi-Quellcode:

procedure TestPrinter;
var
  i: Integer;
begin
  for i := 1 to 100 do
  begin
    Printer.BeginDoc;
    Printer.EndDoc;
    SetPrinter(nil).Free;
  end;
end;

Nur so 'ne Idee...

[nahpets]

Hallo Assertor,

ob man aktiv Leaks, die andere produzieren, vermeiden kann, wage ich zu bezweifeln.
Da ich immernoch nach Handle-Leaks suche und inzwischen zwei Stellen habe ausmachen können (1. WMI, 2. Lesen von Eventlogs per JvNTEventLog), stelle ich mir die Frage:

Wenn SysInternals mit dem ProcessExplorer... feststellen kann, welche Handle zu welchem Prozess gehören und per Menü Rechte Maustaste auch das Schließen dieser Handle ermöglicht, muss es da doch im Betriebssystem irgendwelche passenden Methoden geben.

Was mir vorschwebt wäre eine Methode, die am Anfang einer Routine die Zahl der Handle (ggfls. auch eine Handleliste) zum eigenen Prozess erstellt. Dann wird die Routine ausgeführt und eine erneute Prüfung durchgeführt. Die Differenz zwischen vorher und nachher müsste man dann selbst aufräumen.
Das ist jetzt sicherlich erstmal eine sehr naive Sicht, von der ich momentan nicht weiß, ob und ggfls. wie sie zu realisieren ist.

[OT]befürchte, dass ich schon wieder keine Antwort gebe, sondern weitere Fragen aufwerfe :wink:[/OT]

[Assertor]

Hi,

Zitat:

Zitat von Uwe Raabe

Probier doch mal dies:

Delphi-Quellcode:

procedure TestPrinter;
var
  i: Integer;
begin
  for i := 1 to 100 do
  begin
    Printer.BeginDoc;
    Printer.EndDoc;
    SetPrinter(nil).Free;
  end;
end;

Nur so 'ne Idee...

Gute Idee, aber leider gleiches Ergebnis: Ich hab jetzt schon versucht Brother zu kontaktieren, aber kommt nur der 08/15 "Kundenservice" - der natürlich von sowas keine Ahnung hat. Ich kann das Leak jetzt auf die Datei BROMF04B.dll zurückführen, den Brother Printer Driver 0.3.0.0 (v3.23). Es leaken die weiter obene aufgeführten Objekte.

Da wird ein (Kernel)objekt in der Benutzersession einfach nicht wiederverwendet, sondern pro Druckauftrag angelegt. Wie man das für manche HP- und Brothertreiber generell fixen kann ist eine gute Frage...

Zitat:

Zitat von nahpets

ob man aktiv Leaks, die andere produzieren, vermeiden kann, wage ich zu bezweifeln.
...
Was mir vorschwebt wäre eine Methode, die am Anfang einer Routine die Zahl der Handle (ggfls. auch eine Handleliste) zum eigenen Prozess erstellt. Dann wird die Routine ausgeführt und eine erneute Prüfung durchgeführt. Die Differenz zwischen vorher und nachher müsste man dann selbst aufräumen.
Das ist jetzt sicherlich erstmal eine sehr naive Sicht, von der ich momentan nicht weiß, ob und ggfls. wie sie zu realisieren ist.

Richtige Überlegung, wobei es an sich ja nicht Aufgabe des einen Programmierers sein kann, dynamische Probleme eines anderen auszugleichen. Wenn es jetzt um ein generelles Problem mit einem Betriebssystem geht, nun gut, dann muß man das nunmal machen. Aber bei Leaks anderer Anwendungen ist ja auch Vorsicht geboten:

Man greift in Abläufe ein, die sich u.U. durch neue Treiber oder Anwendungsversionen ändern. Dies kann dann im Gegenzug Probleme verursachen.

Ein Cleanup-Code wie Du Ihn vorgeschlagen hast wäre schon der richtige Ansatz. Die Handles ließen sich ja auch von Delphi aus löschen. Aber wenn man das so machen müßte, liefe mir irgendwie ein kalter Schauer über den Rücken...

Zitat:

Zitat von nahpets

[OT]befürchte, dass ich schon wieder keine Antwort gebe, sondern weitere Fragen aufwerfe :wink:[/OT]

Macht ja nichts :)

Ich überlege derzeit wie ich die problematischen Codeteile, hier den Druck, in einen Childprozess auslagere ohne zusätzliche Hüren zu schaffen.

Bevor ich jetzt das Rad neu erfinde: Kenn jemand ein Beispiel für einen Child-Process zum Drucken?

Zum Drucken wird der Child gestartet, Druckdaten übergeben, der Druck ausgeführt und ein Returncode (und -message) gesendet. Nach jedem Druck wird der Child terminiert, so sollte auch das Handle zerstört werden. Sehe ich das jetzt richtig, oder trügt mich meine Erinnerung?

Gruß Assertor

[nahpets]

Hallo Assertor,

meinst Du über CreateProcess...?
Da bist Du dann bei den gleichen/ähnlichen Überlegungen wie ich. Überlege, ob ich mein Problemprogramm in mehrere aufsplitte und diese von einem Anderen per Timer und ShellExecute... aufrufe.
Prinzipell sollten damit die Handle-Leaks weg (umgangen, auf kurze Zeiträume... reduziert) sein.

Ich weiß nicht, was Du drucken musst. Wäre der Druck in eine Datei eine Alternative, um die Datei nachher per copy datei prn oder ähnlich auszudrucken. Oder hast Du einen PDF-Drucker, an den Du zuerst die Ausgabe machst, um dann die PDF's per Batch... zu drucken.

Nein, ein Beispiel kenne ich nicht, hätte nur (monentan noch vage) Vorstellungen, wie ich es bei meinen Programmen realisieren könnte, wenn sie Druckprobleme haben.

Eventuell hilft Dir aber diese Seite http://www.felix-colibri.com/papers/...in_stdout.html weiter (ziemlich weit unten).