David Haller [29.03.2018 19:04]:
Hallo,
[...]
fstat(14, {st_mode=S_IFREG|0644, st_size=5563, ...}) = 0 fstat(14, {st_mode=S_IFREG|0644, st_size=5563, ...}) = 0 fstat(14, {st_mode=S_IFREG|0644, st_size=5563, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f268de1f000 read(14, "
Hier wird dann _vermutlich_ versuch das SVG zu rendern, da könnte es Probleme geben ... aber
und der Splashscreen öffnet sich. Und die App hängt.
wenn der noch angzeigt wird ... *hmmm*
Yes.
Dürfte nicht relevant sein. Wonach muss ich suchen? Das Ergebnis von strace ist ca. 2 MB groß (2341100 Bytes).
strace ist hier nicht der Holzhammer der Wahl, da braucht man die große Keule namens 'ltrace' ;) Das Tool traced nicht nur die syscalls (wie read, write usw.) sondern Aufrufe von Bibliotheksfunktionen (library calls)... Und kann auch noch die syscalls obendrein... BTW: ltrace und strace sind bei mir grundlegende Debugging-Tools und werden deswegen auch per Profil bei meinem OBS/osc Krams vorinstalliert :)
Also:
$ ltrace -f -s 128 -o quanta.ltrace /usr/bin/quanta $ ltrace -f -s 128 -S -o quanta_syscalls.ltrace /usr/bin/quanta $ su - # ltrace -f -s 128 -o quanta.root.ltrace /usr/bin/quanta # ltrace -f -s 128 -S -o quanta_syscalls.root.ltrace /usr/bin/quanta # chown -c werner.werner quanta*.root.ltrace # exit $
Jeweils bis es für "relevante Zeit" (30s? sowas) hängt.
Die 4 .ltrace komprimierst du dann mit xz (die 2 von root wie angedeutet vorher chownen, 'chown werner.werner' ist exemplarisch, eben so, daß du als user dann die Dateien lesen, komprimieren und mailen kannst):
$ xz -v quanta*.ltrace
und mailst mir die dann 4 quanta*.ltrace.xz per PM(!). Betrachte ein NDA für alle evtl. vertraulichen Informationen die evtl. im trace auftauchen könnten als unterzeichnet, da bleibt nur in meinem Kopf was für's nächste ähnliche Problem :)
Wobei: die Variante mit dem ltrace als root können wir auch gerne erstmal weglassen, da meld ich mich ggfs. halt nochmal per PM, dauert dann eben insgesamt etwas länger.
Gerade die Variante hat mich verblüfft, denn als root öffnet sich die Anwendung. Zwar erst nach >2 Minuten, aber immerhin. Man könnte sogar damit arbyten, wenn man genug Geduld mitbringt. Neues Fenster öffnen + schließen -> 30 Sek.
Ich wühl mich dann mal durch und zitiere (nur) relevantes. Bei paste.opensuse.org kannst du's ja später raufladen, aber grad bei libcalls (und mit so langen Strings) kann durchaus "sensibles" in so einem trace auftauchen, das man lieber nicht im Netz haben will. Z.B. weil gerade ein Desktop-Programm aus Gnome/KDE/XFCE/hastenichgehörtvon gerne mal sämtliches in ~/ abklappert und ~/.* ganz besonders unter die Lupe nimmt... Denk z.B. an Dateinamen die ja per stat/access gern mal auftauchen...
Achso: ich _vermute_ das Problem liegt an (uralten) Qt (Svg) libs
Alte Libs mit ggf. geänderten Schnittstellen habe ich auch vermutet, aber die ldd-Ausgabe zeigt keine Probleme. Und meist kommt ja dann eine Ausgabe wie "unresolved symbol ...", und es kommt gar nichts.
Ah, genau, wenn du schonmal dabei bist: mail auch gleich die *.lst.xz von
$ rpm -qa --last | sed '/ 2017 /q' | xz -c > rpms_2018.lst.xz $ rpm -qa '*qt*' | sort | xz -c > qt_rpms.lst.xz
mit... Ich hab so einen leisen Verdacht, daß eine lib (librsvg z.B.) aktualisiert wurde, und die ollen Qt-libs kommen damit nicht (mehr) klar. Das sollte sich in den ltrace finden lassen. Da hülfe dann nur noch neukompilieren oder ein Downgrade (-> evtl. Sicherheitsproblem).
Aber erstmal ltrace angucken. Vielleicht liege ich ja auch komplett falsch. Alles weitere erstmal per PM...
Du hast eine Mail > 30 MB :) Gruß Werner --