TOpenDialog - Debian Wheezy - AMD64 - Lazarus 1.2.0 GTK2

[ruewa]

TOpenDialog friert auf meinem System eine Zeitlang ein, wenn mehrere Dateien selektiert sind (Standardoptionen mit Ausnahme von ofAllowMultiSelect = True). Der Zeitbedarf ist proportional zur Anzahl der ausgewählten Dateien, ca. 0,3 Sekunden pro Datei, also etwa eine halbe Minute bei 100 Files, wobei die Prozessorauslastung während dieser Zeitspanne gegen 100 % geht. Der Fehler ist bei mir zu 98 % reproduzierbar, vereinzelt, aber selten, tritt der Fehler auch nicht auf. Kurios ist auch: Wenn ich den TOpenDialog öffne und gleich wieder schließe, tritt das Einfrieren reproduzierbar nicht auf. In dem Fall wird die erste Datei automatisch selektiert und taucht in der Files-Liste auf (TOpenDialog.Files.Count = 1). Wenn ich aber diese schon vorselektierte erste Datei explizit anklicke und dann schließe, braucht der Dialog (bei gleichem Ergebnis) statt 12 etwa 300 ms. Mit Qt tritt das Problem nicht auf.

Ich habe einen Bugreport verfaßt (http://bugs.freepascal.org/view.php?id=26110), aber bisher konnte niemand den Bug reproduzieren. Die Vermutung geht dahin, daß es ein spezielles Problem von 64-bit / Linux / GTK 2.24.10-2 / libglib2.0-0 v. 2.33.12+really2.32.4-5 ist. Diese Versionen sind aber Debian Wheezy Standard und man wird sie innerhalb des Paketmanagements nicht einfach los. In anderen Konstellationen zeigt sich der Fehler offenbar nicht.

Ich habe ein kleines Testprogramm geschrieben, das beim Start ein Unterverzeichnis (relativ zum Programm) und darin 200 Dummydateien erstellt. Wenn man einen TOpenDialog öffnet, wird die Anzahl der ausgewählten Dateien und der Zeitbedarf zwischen dem Anklicken des Open-Buttons und dem Schließen des Dialogfensters protokolliert. Normalerweise würde das etwa 10-50 ms benötigen. Beim Schließen des Testprogramms werden die Dummydateien und das Verzeichnis wieder gelöscht.

Kann jemand mit dieser oder einer ähnlichen Rechnerkonstellation den Bug bestätigen?

Gruß Rüdiger

[theo]

Ein bisschen hängt's bei mir auch:

10 Files: 0:00:198 (min:sec:msec)
100 Files: 0:03:241 (min:sec:msec)
200 Files: 0:04:200 (min:sec:msec)

Lazarus 1.3 r45036M FPC 2.7.1 x86_64-linux-gtk 2
gtk2-devel-2.24.10-3.1.2.x86_64

Habe eine SSD.

Ist mir bisher nicht so aufgefallen und ist auch schwer zu vergleichen. Bin nicht sicher, ob Lazarus da was machen kann.
Bei Firefox kann ich gar nicht mehrere auswählen und bei Gimp bleibt der Dialog offen, bis das letzte Bild geladen ist.

Vllt ist das interessant:
S.a: http://stackoverflow.com/questions/9275 ... -files-wit

[ruewa]

Vllt ist das interessant:
S.a: http://stackoverflow.com/questions/9275 ... -files-wit

Herzlichen Dank, Theo! That's it!

Ich habe jetzt mal ausprobiert, was Chris im 2. Posting herausgefunden hat und die Datei /home/~/.local/share/recently-used.xbel auf ReadOnly gesetzt. Das bringt erstmal nichts, weil während der Totzeit ständig neue Dateien wie "recently-used.xbel.LP84EX" etc. erzeugt werden. Tatsächlich rödelt es in dem Verzeichnis gewaltig. Also habe ich kurzerhand das ganze Verzeichnis als ReadOnly deklariert, und siehe da: Das Öffnen von 100 Dateien verkürzt sich von vorher durchschnittlich 35 auf etwa 7 Sekunden. Dazu gab es einen Bugreport im Gnome Bugzilla (https://bugzilla.gnome.org/show_bug.cgi?id=616997), aber in der GTK 2.24 wurde das nicht korrigiert.

Ärgerlich ist halt, daß man in Debian Stable keine Chance hat, das Zeug auf regulärem Weg via Paketmanager loszuwerden, da hängt praktisch das halbe System dran.

Gruß Rüdiger

[theo]

Gut wenn jetzt wenigstens die Ursache klar ist.
Schreibst du das noch in den Bugreport, damit der geschlossen werden kann?
http://bugs.freepascal.org/view.php?id=26110

[ruewa]

Schon geschehen.

Der Bug ist übrigens doch seit GTK 2.24.12 beseitigt (http://upstream-tracker.org/changelogs/ ... gelog.html , Bug 616997), es scheint also (mittlerweile) ein reines Debian-Wheezy-Problem (2.24.10-2) zu sein.