Wir erhalten Kerndateien, wenn wir unsere Software auf einer Kundenbox ausführen. Leider haben wir da immer mit -O2 kompiliertohne Das Debuggen von Symbolen hat zu Situationen geführt, in denen wir nicht herausfinden konnten, warum es abgestürzt ist. Wir haben die Builds so modifiziert, dass sie jetzt -g und -O2 zusammen generieren. Wir empfehlen dem Kunden dann, eine -g-Binärdatei auszuführen, damit das Debuggen einfacher wird.

Ich habe ein paar Fragen:

Was passiert, wenn eine Kerndatei von einer anderen Linux-Distribution als der in Dev ausgeführten erzeugt wird? Ist der Stack-Trace überhaupt sinnvoll?Gibt es gute Bücher zum Debuggen unter Linux oder Solaris? Etwas beispielhaftes wäre toll. Ich suche nach Beispielen aus der Praxis, um herauszufinden, warum eine Routine abgestürzt ist und wie der Autor zu einer Lösung gelangt ist. Etwas mehr für Fortgeschrittene wäre gut, da ich das schon eine Weile mache. Eine Versammlung wäre auch gut.

Hier ist ein Beispiel für einen Absturz, bei dem wir den Kunden anweisen müssen, eine -g ver zu erhalten. der binären:

Program terminated with signal 11, Segmentation fault.
#0  0xffffe410 in __kernel_vsyscall ()
(gdb) where
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x00454ff1 in select () from /lib/libc.so.6
...
<omitted frames>

Idealerweise würde ich gerne herausfinden, warum genau die App abgestürzt ist - ich vermute, es ist Speicherbeschädigung, aber ich bin nicht 100% sicher.

Remote-Debugging ist grundsätzlich nicht zulässig.

Vielen Dank