"nicht genügend arbeitspeicher verfügbar"

[Vjay]

Könnte sich ja mal jmd. die Mühe machen und ein Programm schreiben, welches GDI-Objekte (DCs?) einzeln reserviert, bis es nicht mehr geht und dann kann man ja zusammenzählen ;)

[faux]

Hallo!

Ich kann das nur bestätigen, habe das Selbe problem und wollte schon mal nen Thread schreiben:
Ich habe auch 2 GB Speicher und auch 5 GB Virtual Memory auf der Systemplatte reserviert, jedoch kommt es oft vor, dass ich keine neuen Programme mehr öffnen kann, wenn ich ca 20 Applikationen geöffnet habe (Dienste und Hindergrundprozesse mal ausgeschlossen). Anders macht sich das ganze auch noch bemerkbar: Ich kann keine Menüs mehr öffnen.
Naja, nervt ziemlich, aber sobald ich ein Programm beende, kann ich wieder was öffnen.
Ich denke mal, dass der Speicher sehr ineffizient genutzt wird von Windows. Denn frei wäre der Speicher zwar, aber warscheinlich nicht in ausrechenden sequentiellen Böcken oder so.
Naja, habe auch O&O Clever Cache in der 30 Tage Testzeit laufen, das hilft aber leider auch nicht recht viel.

Naja, mal abwarten.

Grüße
Faux

[Daniel G]

Zitat:

Zitat von sECuRE

Kandidaten für viele GDI-Objekte sind bei mir iTunes (keine Ahnung warum...)

Weil iTunes das komplette Fenster selbst zeichnet....

[shmia]

Zitat:

Zitat von sECuRE

ich habe gehört, dass es bei 10.000 liegt. Weiß aber nicht, warum das so sein soll oder woher die Behauptung kommt.

An dieser Zahl ist wirklich was dran. (auch bei WinXP)
Mein Testprogramm kann auch maximal 10000 Edit-Controls erzeugen und dann kommt die Fehlermeldung:
Win32-Fehler: Code 14
Wer's ausprobieren will:
Ein Formular mit einem Editfeld (Inhalt '1000') + ein Button:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
   i : Integer;
   x : TEdit;
begin
   try
      for i := 1 to StrToInt(Edit1.text) do
      begin
         x := TEdit.Create(Self);

         x.Left := random(Self.Width);
         x.Top  := random(Self.Height);
         x.Parent := Self;
         x.Visible := True;

         x.Text := IntToStr(Self.ControlCount) + '/'+IntToStr(x.Handle);
         Application.ProcessMessages;
      end;
   finally
      Edit1.BringToFront;
      Button1.BringToFront;
   end;
end;

[sECuRE]

Hi,

Zitat:

Zitat von shmia

Zitat:

Zitat von sECuRE

ich habe gehört, dass es bei 10.000 liegt. Weiß aber nicht, warum das so sein soll oder woher die Behauptung kommt.

An dieser Zahl ist wirklich was dran. (auch bei WinXP)
Mein Testprogramm kann auch maximal 10000 Edit-Controls erzeugen und dann kommt die Fehlermeldung:
Win32-Fehler: Code 14
[...]

Ja, das ist aber wieder etwas anderes. Das prozessabhängige Limit liegt klar bei 10.000, ab dann denkt Windows, dass der Prozess ein Memory Leak hat und lässt nicht mehr Objekte zu.

Die 16384 als gloables Limit klingen da schon realistischer.

@Daniel G: Ja, aber die Zahl liegt bei frisch gestartetem iTunes bei ca 700, erhöht sich dann im Laufe der Zeit - ein Memory Leak?

@Opera-Benutzer: In der Changelog von v8.52 stand, dass ein GDI-Leak behoben wurde. Vielleicht waren das einfach nicht alle Leaks, vielleicht ist es aber wirklich nicht Operas Schuld?

cu

[Daniel G]

Zitat:

Zitat von sECuRE

Ja, aber die Zahl liegt bei frisch gestartetem iTunes bei ca 700, erhöht sich dann im Laufe der Zeit - ein Memory Leak?

Wenn es sich um einen Memory Leak handelt, dann müsste man das im Taskmanager sehen, dann würde der Speicherverbrauch immer mehr steigen. Vielleicht ist iTunes ja auch einfach schlampig programmiert und es werden nicht immer alle Handles wieder freigegeben.

[sECuRE]

Hi,

Zitat:

Zitat von Daniel G

Vielleicht ist iTunes ja auch einfach schlampig programmiert und es werden nicht immer alle Handles wieder freigegeben.

Genau das meinte ich in dem Fall ja mit Memory Leak.

cu

[sECuRE]

Hi,

hab' noch etwas gefunden:
http://www.fengyuan.com/bin/gdiobj.zip - Das Tool listet alle Programme und die Anzahl der GDI-Objekte, sortiert nach GDI-Typen auf.

cu

[himitsu]

Hab gerade mal geguckt, aber ein ExplorerFenstere braucht nur etwa 11 MB und knapp 120 GDIs ... 's geht also noch (von den GDIs her)
Man darf ja nicht vergessen, das die Explorer.exe für mehr als nur das eine Fenster zuständig ist ... die kümmert sich ja unter anderem noch um den Desktop und die Startleiste.

Zitat:

Zitat von sECuRE

Ja, das ist aber wieder etwas anderes. Das prozessabhängige Limit liegt klar bei 10.000, ab dann denkt Windows, dass der Prozess ein Memory Leak hat und lässt nicht mehr Objekte zu.

Wie kann es das einfach so machen ... was wäre, wenn man wirklich soviele braucht und es kein Leak ist? -.-''

[sECuRE]

Hi,

Zitat:

Zitat von himitsu

Zitat:

Zitat von sECuRE

Ja, das ist aber wieder etwas anderes. Das prozessabhängige Limit liegt klar bei 10.000, ab dann denkt Windows, dass der Prozess ein Memory Leak hat und lässt nicht mehr Objekte zu.

Wie kann es das einfach so machen ... was wäre, wenn man wirklich soviele braucht und es kein Leak ist? -.-''

Es gibt eine Möglichkeit, das Prozessabhängige Limit zu erhöhen. In der Regel sollte es aber ganz einfach nicht so viel brauchen - Nunja, Windows eben ;).

cu