Brauche Hilfe bei der Lösung segfault in der libc-2.23.so

Brauchen Hilfe shared library Debuggen mit gdb.

Ich versuche zu Debuggen, die eine shared-library und in meinem Fall ist es:

libc-2.23.so

Der Grund ist, dass ich diese Zeilen in der Ausgabe von dmesg: 

[10081.433266] compiz[11346]: segfault at 7f30a4100010 ip 00007f309c36f44b sp 00007ffdde303aa0 error 4 in libc-2.23.so[7f309c2f1000+1bf000]
[22005.764635] compiz[16149]: segfault at 7f30e3456db0 ip 00007f30db85044b sp 00007fffaab9c0a0 error 4 in libc-2.23.so[7f30db7d2000+1bf000]
[48777.031064] compiz[25203]: segfault at 7f0b8e23b050 ip 00007f0b87edf44b sp 00007ffd51d15740 error 4 in libc-2.23.so[7f0b87e61000+1bf000]
[78850.413793] compiz[4889]: segfault at 7f60ddbf2440 ip 00007f60d598944b sp 00007ffedc5e31b0 error 4 in libc-2.23.so[7f60d590b000+1bf000]
[84583.754783] compiz[8441]: segfault at 7f5f8c3930c0 ip 00007f5f871d544b sp 00007ffc436bb5a0 error 4 in libc-2.23.so[7f5f87157000+1bf000]
[100625.457854] compiz[15619]: segfault at 7ffffa967680 ip 00007ffff722844b sp 00007fffffffdad0 error 4 in libc-2.23.so[7ffff71aa000+1bf000]
[104234.596331] compiz[19076]: segfault at 7ffffa2dc540 ip 00007ffff722844b sp 00007fffffffd810 error 4 in libc-2.23.so[7ffff71aa000+1bf000]
[112314.238115] compiz[22152]: segfault at 7ffffe232760 ip 00007ffff722844b sp 00007fffffffd810 error 4 in libc-2.23.so[7ffff71aa000+1bf000]
[130828.195732] compiz[26013]: segfault at 7ffffa966180 ip 00007ffff722844b sp 00007fffffffdad0 error 4 in libc-2.23.so[7ffff71aa000+1bf000]
[225379.026592] compiz[19275]: segfault at 7ffff821b6d0 ip 00007ffff722844b sp 00007fffffffd7c0 error 4 in libc-2.23.so[7ffff71aa000+1bf000]

Die Adresse, wo libc-2.23.so geladen ist, ändert sich nicht nach Zeitstempel 100625.457854 da ich den Befehl ausgeführt:

$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Um der Lage sein, um es zu laden unter gdb.

Was ich bisher getan habe ist, dass ich haben festgestellt, dass der segfault immer auftreten, auf der gleichen Abstand von der gemeinsamen Bibliotheken geladen-Adresse.

Ich berechnet den offset durch die Einnahme instruction-pointer minus-laden-Adresse in python: 

ld = ["7f309c2f1000", "7f30db7d2000", "7f0b87e61000", "7f60d590b000", "7f5f87157000", "7ffff71aa000"]
ip = ["7f309c36f44b", "7f30db85044b", "7f0b87edf44b", "7f60d598944b", "7f5f871d544b", "7ffff722844b"]
ld_val = [int(x,16) for x in ld]
ip_val=[int(x,16) for x in ip]
ip_off=[i-s for (i,s) in zip(ip_val,ld_val)]
ip_off
[517195, 517195, 517195, 517195, 517195, 517195]

Also verwenden diese Informationen, ich habe die betreffende Zeile aus der Ausführung:

$ addr2line -e /lib/x86_64-linux-gnu/libc-2.23.so -fCi 0x7e44b

malloc_consolidate

/build/glibc-9tT8Do/glibc-2.23/malloc/malloc.c:4167

Da läuft mir Ubuntu 16.04 habe ich installiert, die Quellen durch die Ausstellung:

$ apt-get source glibc-source -

Einsichtnahme in die betreffende Zeile zeigte, dass es war nur ein Kommentar.

malloc.c:4167 

/* Slightly streamlined version of consolidation code in free() */

innerhalb der Funktion: 

static void malloc_consolidate(mstate av)

So, ich bin angenommen, ich bin etwas falsch hier.

Alle Zeiger auf, wie Sie zur Erfassung dieser "segmentation Fault"?

  • Was würde ich gerne sehen, ist die Ausgabe nach catch throw (exception fangen) dann backtrace (Anzeige auf dem Aufruf-stack). Diese geben uns eine Spur, wo das problem herkommt, da ist es viel wahrscheinlicher in deinem eigenen code, nicht in glibc.
  • Vielen Dank für die Antwort, aber compiz ist nicht mein code und selbst wenn es war, ich würde noch brauchen, um zu wissen, wo die catch-throw - code.
  • Diese beiden Befehle sind für gdb vor dem ausführen des Programms; wenn das problem in compiz Datei einen Fehler mit dem Betreuer. BTW, dies könnte ein Bereich zu untersuchen.
  • Ich folgte den Anweisungen auf der post zu ermitteln, aber bin immer noch nicht mit apport-retrace nicht finden konnten, einen öffentlichen Schlüssel für compiz_0.9.12.2+16.04.20160823-0ubuntu1.dsc. Weiterhin, da sollte es möglich sein.
  • Gab es irgendwelche Warnmeldungen, wenn Sie lief apt-get source glibc-source? Ich nur lief, und line-4167 von malloc.c ist nextsize = chunksize(nextchunk);. Der Kommentar in Ihrem line-4167 ist in meiner Linie 4164. Dies könnte erklärt werden durch Ihre apt-get source nicht angewandt habe der debian/patches/git-updates.diff patch löscht ein paar Zeilen um die Zeile 1074.
  • Ich habe gerade ausgeführt, der Befehl erneut ein, und nichts mehr als gpgv-problem nicht mit der Suche nach öffentlichen Schlüssel und, dass es ausgewählt "glibc", die als source-Paket statt "glibc-source". Es auch reccomends zu tun, einen git-Klon: git clone https://anonscm.debian.org/git/pkg-glibc/glibc.git was ich auch Tat, aber ich fand keine Quelle Dateien im repo. Ohnehin, so dass Sie denken, dass es eine Diskrepanz zwischen den von malloc.c aus apt-get source glibc-source und meine libc-2.23.so?
  • Die git Nachricht ist nur für den Fall Sie möchten, um neuere Quellen als das, was Ubuntu bietet, und die gpgv Nachricht ist nicht wirklich wichtig, wenn Sie Dateien aus einem offiziellen repo mit einem zuverlässigen Internet-Verbindung. Aber kurz nach der gpgv-Nachricht, sehen Sie dpkg-source: info: unpacking glibc_2.23-0ubuntu7.debian.tar.xz gefolgt von dpkg-source: info: applying git-updates.diff ?
  • Ich sehe folgende: dpkg-source: info: packar upp glibc_2.23-0ubuntu7.debian.tar.xz gefolgt von dpkg-source: info: tillämpar git-updates.diff also ja, es sieht das gleiche. Wie kommen die ./malloc/malloc.c unterscheidet? Meine sha256sum ist es: 232551177cf27c79f1fe2dab3f2086424ae35a3120bcdb02aa3956507df73658und es gibt ein anderes malloc.c im Ordner ./.pc/git-updates.diff/malloc/malloc.c was anders ist.
  • Mir hat die selben sha256-Summe. 232551177cf27c79f1fe2dab3f2086424ae35a3120bcdb02aa3956507df73658 ./glibc-2.23/malloc/malloc.c Wenn Sie es Bearbeiten und gehe zu Zeile 4167, sehen Sie das nicht nextsize = chunksize(nextchunk); ?
  • Mit ATOM-editor muss ich gehen, um die Linie 4169 aber mit gedit ist es 4167. Ich denke, wir schließen diese Diskussion. Ich hatte gdb geladen, mit der Bibliothek und Haltepunkt auf Zeile 4167 aber keine Pause, auch wenn ich einen neuen Eintrag in dmesg.

InformationsquelleAutor IgorLopez | 2017-06-06
  1. 1

    So, ich bin angenommen, ich bin etwas falsch hier.

    Sind Sie nicht.

    Symptome, die Sie auf der Suche sind zu 99,999% das Ergebnis einer heap-Beschädigung, und da dies geschieht in compiz, es gibt wenig Sie tun können, außer einen bug-report.

    Um einen brauchbaren bug report, es würde helfen, wenn Sie laufen konnte compiz unter Valgrind. Es läuft unter GDB wird nicht helfen.

    Hatte ich gdb geladen, mit der Bibliothek und Haltepunkt auf Zeile 4167 aber keine Pause, auch wenn ich einen neuen Eintrag in dmesg.

    Dass bedeutet, dass Sie Debuggen den falschen Prozess. Vielleicht compiz Gabeln helper-Prozesse, und einer von Ihnen stirbt?

    InformationsquelleAutor Employed Russian
Schreibe einen Kommentar