Fehler:KDE

aus openSUSE, der freien Wissensdatenbank

KDE-Fehlerberichte

Allgemein

Beim Einreichen von Fehlerberichten auf bugzilla.novell.com ist es sinnvoll zu wissen, welche Pakte installiert sind. Manche Leute haben nur die gewöhnlichen von openSUSE veröffentlichten Pakete installiert (manchmal mit und manchmal ohne Online-Aktualisierungen) und andere haben ihr KDE aus den Build Service-Paketdepots von software.opensuse.org aktualisiert. Einige haben sogar experimentelle Pakete laufen, die eventuell noch weitere Fehler enthalten können.

Weitere Informationen: KDE debuggen

Stellen Sie bitte sicher, dass Sie alle relevanten Informationen beifügen (im Zweifel auch eine Liste ihrer Paketquellen). Sie sollten vorher auch mal auf bugs.kde.org vorbeischauen, um zu überprüfen, ob es sich nicht vielleicht um einen nicht-openSUSE-spezifischen Fehler handelt. Sie können den Bericht immer noch an openSUSE senden, so wird er vielleicht als UPSTREAM geschlossen oder nicht behoben, bis eine behobene Version aus dem Ursprungsprojekt erhältlich ist. Kritische Fehler, ob aus dem Ursprungsprojekt oder openSUSE-spezifisch, werden vom KDE Team bei openSUSE bevorzugte Aufmerksamkeit erfahren, nach anderen openSUSE-spezifischen Fehlern und anderen KDE-Fehlern.

Nützliche Absturzberichte

Ablaufverfolgungen (backtraces) sollten immer nur mit installierten -debuginfo-Paketen gemeldet werden. Falls der Text des Berichts zur Ablaufverfolgung Stellen wie "This backtrace appears to be of no use." enthält, dann fehlen ihnen entweder die debuginfo-Pakete oder die Versionen stimmen nicht überein. Sie können diese Pakete auch noch installieren, wenn Dr. Konqi erscheint - bevor Sie auf den Backtrace-Reiter klicken, allerdings müssen sie aus der gleichen Quelle stammen, aus der auch die Anwendungspakete kommen (beta2-Debuginfo passt nicht zu beta1-Anwendungen). Normalerweise benötigen Sie dazu kdepim3/4-debuginfo, kdelibs3/4-debuginfo, kdebase3/4-debuginfo und qt3-debuginfo bzw. libqt4-debuginfo.

Jedes Quellpaket generiert eine debuginfo, wird aber vielleicht selber in viele binäre RPMs aufgeteilt. Dies erschwert die Suche nach der zu installierenden debuginfo. Wenn Sie nicht sicher sind, welche debuginfo Sie brauchen, dann gehen Sie wie folgt vor:

• Identifizieren Sie den Prozess, der abgestürzt ist, bspw. /usr/bin/kwin
• Finden Sie heraus, in welchem RPM die Datei gepackt ist: "rpm -qf /usr/bin/kwin" zeigt, dass kwin Teil von kde4-kwin ist.
• Finden Sie heraus, aus welchem Quellpaket das binäre RPM erstellt wurde: "rpm -qi kde4-kwin | grep Source\ RPM" zeigt, dass sich die Quellen von kwin in kdebase4-workspace befinden.
• Installieren Sie das zugehörige debuginfo-Paket, in diesem Fall kdebase4-workspace-debuginfo.

Wenn Sie viele Tests durchführen oder oft Fehler suchen, dann hilft es, debuginfos der Basis-KDE-Plattform installiert zu haben. Das sind

• libqt4-debuginfo
• kdelibs4-debuginfo
• kdepimlibs4-debuginfo
• kdebase4-runtime-debuginfo
• kdebase4-workspace-debuginfo

Um Fehler gegen Factory oder openSUSE Beta-Versionen zu melden, müssen sowohl das Factory-Depot als auch das zugehörige Debuginfo-Depot eingebunden sein - Betas haben keine debuginfo-Pakete. Installieren Sie das zugehörige Paket von Factory und seine debuginfo- und debugsource-Unterpakete um gute Rückverfolgungen mit Zeilennummern zu erhalten.

Weitere Informationen: Leitfaden für KDE-Fehlerberichte

Spezifische Hinweise und Tricks

Normalerweise ist $HOME/.xsession-errors die einzig sinnvolle Protokolldatei - lediglich für Fehler im KDM und während der Anmeldung werden auch noch weitere gebraucht, namentlich /var/log/messages, /var/log/kdm.log und /var/log/Xorg.0.log.

Das Debuggen von kio_slaves (jedes Problem mit einem Protokoll in Konqueror bspw.) ist ein wenig komplizierter. Eine Beschreibung für diese Fälle finden Sie hier .

Wenn Sie einem Prozess GDB anhängen, dann denken Sie daran, dass wenn der Prozess "[kdeinit]" im Namen trägt, die richtige Startdatei nicht bspw. dcopserver ist, sondern kdeinit.