Am 09.10.18 09:57 schrieb Hugo:
Hallo Herbert, Am Montag, 8. Oktober 2018, 20:22:17 CEST schrieb Herbert Albert:
Am Montag, 8. Oktober 2018, 12:30:12 CEST schrieb Hugo:
Hallo Herbert und andere
Am Sonntag, 7. Oktober 2018, 19:36:55 CEST schrieb Herbert Albert:
Am Sonntag, 7. Oktober 2018, 17:28:40 CEST schrieb Norbert Zawodsky:
Hallo Liste,
hat das vielleicht noch jemand beobachtet?
Seit einige Zeit - ich GLAUBE seit dem upgrade auf Leap 15 startet hat gimp ein äußerst eigenartiges Verhalten:
Beim 1. Mal startet gimp wie gewohnt. Beende ich gimp und will starte ihn neu, dann startet er zukünftig nur mehr ohne sichtbare Fenster. Er scheint zwar in der Prozessliste (Strg-ESC, oder ps) als ganz normal laufend auf, aber es ist nichts zu sehen.
Das einzige, das dagegen hilft ist ~/.gimp-2.8 zu löschen UND gimp neu zu installieren. Dann startet er das 1. Mal mit sichtbaren Fenstern, danach aber wieder nur mehr "unsichtbar".
Sehr seltsam... Hat jemand von Euch eine Idee dazu?
Grüße, Norbert Hallo Norbert,
bei mir startet gimp auch nicht. Starten in der Konsole ergibt keine Rückmeldung (es gibt keine Konsolenoutput). Ist wohl so gedacht! hmahr> man gimp hmahr> gimp --verbose INIT: gimp_load_config Parsing '/home/pmahr/.gimp-2.8/unitrc' Parsing '/etc/gimp/2.0/gimprc' Parsing '/home/pmahr/.gimp-2.8/gimprc' gimp_composite: verbose=no Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis etc. ...
Starte ich gimp alleine bekomme ich eine Warnung, die ich nicht schön finde: hmahr> gimp
(gimp:3494): GLib-GObject-WARNING **: g_object_set_is_valid_property: object class 'GeglConfig' has no property named 'cache-size' hmahr>
Viele Grüße
Hugo Mahr also gimp --verbose läuft gar nicht, keine Rückgabe auf der Konsole. ~> gimp -v GNU Image Manipulation Program Version 2.8.22 git-describe: GIMP_2_8_20-60-ge39a4e1203
verwendet GEGL Version 0.3.34 (gebaut gegen Version 0.3.34) verwendet GLib Version 2.54.3 (gebaut gegen Version 2.54.3) verwendet GdkPixbuf Version 2.36.10 (gebaut gegen Version 2.36.10) verwendet GTK+ Version 2.24.32 (gebaut gegen Version 2.24.32) verwendet Pango Version 1.40.13 (gebaut gegen Version 1.40.13) verwendet Fontconfig Version 2.12.6 (gebaut gegen Version 2.12.6) verwendet Cairo Version 1.15.10 (gebaut gegen Version 1.15.10) gimp -v ergibt hier dasselbe. Aber das ist NICHT verbose sondern gibt die Versionsinformation zurück. https://wiki.gimp.org/index.php/Users:Tips#On_Linux, Überschrift 'Getting and posting the output of gimp --verbose' schreibt '2 Enter gimp --verbose --console-messages'. Das gibt - bei mir - ca. 115 Zeilen aus, bevor im GUI eine Eingabe kommt.
Vielleicht hilft das ja. Ich hoffe, daß man hier sieht, wo gimp hängen bleibt. Geht das wirklich nicht, wäre es interessant, das Warum zu untersuchen.
Gruß Hugo
Ich habe dieses Phänomen ein wenig weiter beobachtet. 1. interessante Frage ist, wieso funktioniert es scheinbar wieder wenn man gimp "neu installiert", oder eigentlich nur updated (Im Yast einfach nur "unbedingt aktualisieren") 2. Beobachtung: wenn man "lange genug" gimp nicht startet (z.B. über Nacht) geht es danach genau 1x wieder Für mich riechen diese 2 Beobachtungen danach, dass nach dem 1. Lauf irgendetwas im Memory zurück bleibt, dass Gimp beim Start abfrägt. Wenn diesese irgendetwas zufällig noch im Speicher residiert, hängt gimp bei den darauffolgenden Startversuchen. Ist dieses irgendetwas jedoch zwischenzeitlich rausgeflogen,startet gimp wieder problemlos. Ich habe gimp versuchsweise mal in strace laufen lassen. Die letzten Zeilen im trace bis gimp hängt sind: --------------------------------------------------------------------- clone(child_stack=0x7fce36fe0830, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fce36fe19d0, tls=0x7fce36fe1700, child_tidptr=0x7fce36fe19d0) = 14765 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fce35fe0000 mprotect(0x7fce35fe1000, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 clone(child_stack=0x7fce367df830, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fce367e09d0, tls=0x7fce367e0700, child_tidptr=0x7fce367e09d0) = 14766 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fce350af000 mprotect(0x7fce350b0000, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 clone(child_stack=0x7fce358ae830, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fce358af9d0, tls=0x7fce358af700, child_tidptr=0x7fce358af9d0) = 14767 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fce348ae000 mprotect(0x7fce348af000, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 clone(child_stack=0x7fce350ad830, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fce350ae9d0, tls=0x7fce350ae700, child_tidptr=0x7fce350ae9d0) = 14768 munmap(0x7fce3f4ef000, 252723) = 0 futex(0x7fce50783908, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7fce387e49d0, FUTEX_WAIT, 14762, NULL) = 0 futex(0x7fce367e09d0, FUTEX_WAIT, 14766, NULL --------------------------------------------------------------------- gimp wartet offensichtlich im futex() call "ewig" ..... Vielelicht liest ja hier ein linux-programmierer mit Erfahrung mit Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org