Interner TWebBrowser füllt Arbeitsspeicher bis KnockOut

[bogdan]

Ich muss in einer Windows Applikation einen internen TWebBrowser nutzen.
Leider habe ich das Problem, dass der TWebBrowser den Arbeitsspeicher bis zum KnockOut füllt.

Getestet habe ich das ganze auch mit einer Schleife die zb. 100x hintereinander eine TWebBrowser Componente erstellt, dann eine Seite lädt und die Compo wieder frei gibt:

for i := 1 to 100 do
begin
WebBrowser := TWebBrowser.Create(nil)
WebBrowser.Navigate(seite);
WebBrowser.Free;
end;

Auch wenn die WebBrowser-Componente wieder frei gegeben wird, wird der Arbeitsspeicher trotzdem nicht geleert.

Hat Jemand eine Idee woran das liegen kann?

[Der schöne Günther]

Ich würde als erstes einmal testen inwiefern die Seite (und die geladenen Add-Ons) davon abhängig sind. Mit trivialen Dingen wie "about:blank" auch? In einer frischen VM auch?

Ich hatte das neulich einmal mit diesem fürchterlichen Adobe PDF-Plugin. Das Plugin hat in einer bestimmten Version fröhlich Speicherlecks erzeugt. Hat man ein paar mal eine PDF damit angezeigt war der Speicher rappelvoll und das ganze System ist irgendwann mit einem Seufzer in sich zusammengesackt.

[Bernhard Geyer]

Da gibts ein paar Fragen:

Welche Delphi-Version verwendest du? In älteren sind noch ein paar unschönheiten drin die u.U. zu speicherlücken führen könne.
Sinnvoll ist es u.U. TEmbeddedWB zu verwenden wenn die Delphi-Version älter ist.

Dein Beispiel ist ungünstig zum Testen. Ein IEControl ohne gültigen Fensterhandel zum darstellen funktioniert nicht sehr zuverlässig

Vor einem Freigeben sollte man "about:blank" laden um evtl. geladenen ActiveX-Controls die möglichkeit zum aufräumen zu geben.

[bogdan]

@ Günther:
ja, das ist auch Webseiten abhängig wie schnell der RAM dicht ist.
Die geladenen Seiten sind verschieden aufgebaut, die Einen haben mehr Java, Adobe, etc. die Anderen weniger Schnick-Schnack.
Ich selber programmiere die WebPages nicht, nur die Delphi-App.

@ Bernhard:
Ich verwende Delphi XE8.

Zitat:

"Vor einem Freigeben sollte man "about:blank" laden um evtl. geladenen ActiveX-Controls die möglichkeit zum aufräumen zu geben."

Das probiere ich gleich aus.

[Bernhard Geyer]

Zitat:

Zitat von bogdan (Beitrag 1367095)

... Java ...

Wirklich noch Java (im Browser)?
oder nicht doch JavaScript (Was komplett was anderes ist)

[Der schöne Günther]

Ist Java im Browser schon so exotisch? Gerade was öffentliche Stellen angeht sind dicke Java-Applets (die alle Nase lang einmal mit Adminrechten gestartet werden wollen um etwas zu aktualisieren) eigentlich der Hit 8-)

[Bernhard Geyer]

Zitat:

Zitat von Der schöne Günther (Beitrag 1367102)

Ist Java im Browser schon so exotisch? Gerade was öffentliche Stellen angeht sind dicke Java-Applets (die alle Nase lang einmal mit Adminrechten gestartet werden wollen um etwas zu aktualisieren) eigentlich der Hit 8-)

Ein JavaApplet könnte sehr gut eine Ursache für Speicherzuwachs sein.

[nahpets]

Also die Routine sähe bei mir allenfalls so aus:

Delphi-Quellcode:

WebBrowser := TWebBrowser.Create(nil);
for i := 1 to 100 do
begin
  WebBrowser.Navigate(seite);
  // Hier eventuell warten, bis die Seite vollständig geladen wurde.
  // Dafür kann man WebBrowser.Busy abfragen und ggfls. 'ne kleine Pause einlegen.
end;
WebBrowser.Navigate('about:blank');
WebBrowser.Free;

Käme nie auf die Idee für jedes Navigate eine eigene Instanz von TWebBrowser zu produzieren.

Wenn ich den schon dynamisch zur Laufzeit im Programm erstellen muss, dann nur genau einmal. Entweder beim Programmstart oder zu dem Zeitpunkt, an dem ich ihn erstmalig benötige. Beim Programmende wird dann gefragt, ob eine Instanz erstellt wurde, wenn ja, wird sie freigegeben.

Aber eventuell wären etwas genauere Infos zum konkreten Sachverhalt sinnvoll. Gehe mal davon aus, dass die For-Schleife nur entstanden ist, um das Speicherproblem darzustellen.

Also kurz: Wann, warum, wieso, weshalb werden zur Laufzeit des Programmes wieviele TWebbrowser benötigt.
Kurze, grobe Info reicht vollkommen aus.
Eventuell fällt dann ja irgendwem eine passende Lösung ein, die das Problem zumindest verkleinert oder hoffentlich behebt.

[bogdan]

@nahpets:
Ja, die Schleife ist zum Testen da.
Es spielt aber auch keine Rolle ob nur 1x TWebBrowser während der Laufzeit erstellt wird und dann 100 oder mehr Seiten in der einen Instanz navigiert werden oder ob die TWebBrowser-Instanz immer wieder erstellt wird -> Seite lädt -> Instanz wieder frei geben. Das Ergebnis ist immer das gleiche, irgendwann mal ist der RAM voll.

Mit IdHTTP habe ich den gleichen Sachverhalt getestet, da ist alles in Ordnung.

@Bernhard:
"about:blank" hat schon mal bewirkt, dass der RAM nicht so schnell dicht wird.
d.h. bei 100 Seiten war schnell der RAM mit 1 GB zugebaut.
Mit "about:blank" waren bei 1000 Seiten erst mal "nur" 600 MB im RAM.

Anbei der Test-Code:

Code:

function sBrowser(sBrowserName: String; sUrl: String): String;
var
  xBrowser: TWebBrowser;
begin
  if sBrowserName = 'BrowserOnFly' then
  begin
    xBrowser := TWebBrowser.Create(Form1);
    TWinControl(xBrowser).Name := 'BrowserOnFly';
    TWinControl(xBrowser).Parent := Form1.Panel1;
    xBrowser.Align := alClient;
    xBrowser.Silent := True;
    xBrowser.OnBeforeNavigate2 := Form1.WebBrowser1BeforeNavigate2;
    xBrowser.OnDocumentComplete := Form1.WebBrowser1DocumentComplete;
    xBrowser.OnNavigateComplete2 := Form1.WebBrowser1NavigateComplete2;
    xBrowser.OnStatusTextChange := Form1.WebBrowser1StatusTextChange;
    Form1.AdvComboBox1.Text := sUrl;
  end;

  if sBrowserName = 'WebBrowser1' then
  begin
    xBrowser := Form1.WebBrowser1;
  end;

  try
    xBrowser.Navigate(sUrl);
    repeat
      Application.ProcessMessages
    until Form1.FDocLoaded;
  finally
    if sBrowserName = 'BrowserOnFly' then
    begin
      xBrowser.Navigate('about:blank');
      xBrowser.Free;
    end;
  end;
end;

procedure TestBrowser(sBrowserName: String);
var
  i : Integer;
begin
  for i := 1 to 100 do
  begin
    sBrowser(sBrowserName, sGetUrlFromLine(i));
  end;
end;

procedure TForm1.sButton38Click(Sender: TObject);
begin
  TestBrowser(Edit1.Text);
end;

[Bernhard Geyer]

Und was passiert in den Events:

Delphi-Quellcode:

    xBrowser.OnBeforeNavigate2 := Form1.WebBrowser1BeforeNavigate2;
    xBrowser.OnDocumentComplete := Form1.WebBrowser1DocumentComplete;
    xBrowser.OnNavigateComplete2 := Form1.WebBrowser1NavigateComplete2;
    xBrowser.OnStatusTextChange := Form1.WebBrowser1StatusTextChange;

Bis XE8 "fette" Speicherlücken wenn man mit dem Defaultinterface gearbeitet hat.
Siehe: https://marc.durdin.net/2012/07/unde...-olectrls-pas/