☰

Was ist der Unterschied zwischen einem RPM-Debuginfo-Paket und dem Neuerstellen eines Pakets mit einer Option wie -g?

tag-icon • tag-icon package-management rpm debugging
Was ist der Unterschied zwischen einem RPM-Debuginfo-Paket und dem Neuerstellen eines Pakets mit einer Option wie -g?

Ich hätte gern eine Erklärung, wie Debuginfo-Pakete von RPM verwendet werden. Angenommen, ich habe das Paket vimund habe einen Absturz festgestellt. Ich möchte diesen Absturz debuggen, aber gdbich erhalte Fehlermeldungen, weil gdbich keinen Zugriff auf die Zeilennummerninformationen habe. In meinen Augen habe ich zwei Möglichkeiten:

  1. Installieren Sie das Debuginfo-Paket
  2. Erstellen Sie das vimRPM neu und installieren Sie es mit CFLAGS, CXXFLAGS, und LDFLAGSmit -g3oder etwas Ähnlichem.

Ich habe vor Kurzem Option 1 ausprobiert und bekomme immer noch einige Fehlermeldungen über fehlende Symbole von gdb, was zu dieser Frage führte, da ich einige Annahmen darüber machte, was Debuginfo-Pakete sind und wie sie verwendet werden. Könnten Sie bitte die Unterschiede zwischen den oben aufgeführten Optionen 1 und 2 erklären oder, falls ich falsch liege, wie man dies richtig erreicht?

Antwort1

Ich habe vor Kurzem Option Nr. 1 ausprobiert und erhalte immer noch einige Fehlermeldungen bezüglich fehlender Symbole von gdb, was zu dieser Frage führte, da ich einige Annahmen darüber anstellte, was Debuginfo-Pakete sind und wie sie verwendet werden.

Der Absturz liegt möglicherweise nicht an der Anwendung selbst, sondern beispielsweise an glibc oder einer anderen Bibliothek, von der vim abhängt. Das bedeutet, dass Sie Debuginfo-Pakete für alle relevanten Bibliotheken installieren müssen.

Das bedeutet auch, dass das Erstellen von Vim aus Quellen höchstwahrscheinlich zum gleichen Problem führt: Einige Debugsymbole werden nicht aufgelöst. Wenn Sie ein Paket selbst erstellen, sind Ihre Kompilierungsflags außerdem anders als die von Fedora verwendeten, und dann kann es zu demselben Absturz kommen, möglicherweise aber auch nicht.

Antwort2

@Artem hat Recht – Sie benötigen Debuginformationen zu allen transitiven Abhängigkeiten.

Es kann mühsam sein, sie alle zu finden. Sie können das mit ABRT ( dnf install abrt) ganz einfach machen. Wenn etwas abstürzt, wird es von ABRT aufgezeichnet. Auf meinem System beispielsweise:

$ abrt     
071eb9c 1x /usr/libexec/mysqld 2020-06-24 00:55:09
7552a02 1x mariadb 2020-06-26 15:37:45
$ abrt backtrace 071eb9c
Problem has no backtrace
Start retracing process? [y/N] y
Upload core dump and perform remote retracing? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. Local retracing requires downloading potentially large amount of debuginfo data [y/N] n
Local retracing
Analyzing coredump 'coredump'
Cleaning cache...
Cache cleaning has finished
...

verwandte Informationen