Zwei Fragen zu Themen

Question

1. Wenn es eine fehlende/beschädigte Bibliothek im gdb-Kern gibt, wie isoliere ich es?

2. Ich habe auch gelesen, dass es eine Möglichkeit gibt, dass der Thread seinen eigenen Stack überschrieben haben könnte, wie erkenne ich das?

Wie isoliere ich die oben genannten Probleme mit dem untenstehenden BT?

/etc/gdb/gdbinit:105: Error in sourced command file: 
Error while executing Python code. 
Reading symbols from /opt/hsp/bin/addrman...done. 

warning: Corrupted shared library list: 0x0 != 0x7c8d48ea8948c089 

warning: Corrupted shared library list: 0x0 != 0x4ed700 

warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x7ffd50ff6000 
Core was generated by `addrman --notification-socket 
/opt/hsp/sockets/memb_notify.socket'. 
Program terminated with signal 11, Segmentation fault. 
#0 0x00000000004759e4 in ps_locktrk_info::lktrk_locker_set (this=0x348, 
locker_ip=<optimized out>) at ./ps/ps_lock_track.h:292 
292  ./ps/ps_lock_track.h: No such file or directory. 
(gdb) bt 
#0 0x00000000004759e4 in ps_locktrk_info::lktrk_locker_set (this=0x348, 
locker_ip=<optimized out>) at ./ps/ps_lock_track.h:292 
#1 0x0000000000000000 in ??() 

Answer 1

Es sieht so aus, als ob die Core-Datei beschädigt ist, wahrscheinlich aufgrund von Heap- oder Stack-Beschädigung. Korruption ist häufig das Ergebnis eines Pufferüberlaufs oder eines anderen undefinierten Verhaltens.

Wenn Sie unter Linux laufen, würde ich Valgrind versuchen. Es kann oft Korruption sehr schnell erkennen. Windows hat einige ähnliche Tools.

Ja, eine Multithreadanwendung kann den Stapel überlaufen lassen. Jedem Thread wird nur ein begrenzter Betrag zugewiesen. Dies geschieht normalerweise nur, wenn Sie einen sehr tiefen Funktionsaufruf-Stack haben oder wenn Sie ein großes lokales Objekt auf dem Stack zuweisen.

Einige interessante Informationen here und here zum Festlegen der Stapelgröße für Linux-Anwendungen.

mit Ihrem Problem konfrontiert, würde ich:

1. alle Anrufer der lktrk_locer_set Methode überprüfen. untersuchen sorgfältig jedes, wenn möglich, zu sehen, ob es offensichtlich Stack-Überlauf oder Heapbeschädigung
2. Versuchen zu verwenden Valgrind oder ähnliche Werkzeuge Problem Das Problem
3. hinzufügen Debug-Protokollierung zu beschmutzen

Answer 2

zu isolieren warning: Corrupted shared library list: 0x0 != 0x7c8d48ea8948c089

der obige Fehler ist in der Regel ein Zeichen, dass Sie GDB verschiedene Systembibliotheken gab (oder die Haupt binär) von den Gebrauchten, wenn die Core-Dump erzeugt wurde.

Entweder Sie analysieren einen "produktiven" Core-Dump auf einem Entwicklungscomputer oder Sie haben Systembibliotheken zwischen dem Zeitpunkt, an dem der Core-Dump erstellt wurde, und dem Analysieren des Systems aktualisiert oder die Hauptbinärdatei neu erstellt.

Siehe this answer für was zu tun, wenn einer der oben genannten richtig ist.