Gewusst wie: Debuggen "segmentation fault"?

Funktioniert es, wenn in der Schleife, ich setze jedes element auf 0 oder entry_count-1.
Es funktioniert, wenn ich es so einrichten, dass entry_count ist klein, und ich Schreibe es per hand statt per loop (sorted_order[0] = 0; sorted_order[1] = 1; ... usw).

Bitte Sag mir nicht, was zu tun ist, zu beheben mein code. Ich werde nicht mit intelligente Zeiger oder Vektoren für sehr spezifische Gründe. Konzentrieren Sie sich stattdessen auf die Frage:
Welche Art von Bedingungen kann dazu führen, diese segfault?
Danke.

---- ALTER -----

Ich versuche, code zu Debuggen, das funktioniert nicht auf einer unix-Maschine. Die Kernaussage der code ist:

int *sorted_array = (int*)memory;
//I know that this block is large enough
//It is allocated by malloc earlier

for (int i = 0; i < entry_count; ++i){
  sorted_array[i] = i;
}

Scheint es einen segfault irgendwo in der Schleife. Umschalten in den debug-Modus, leider, macht den segfault stoppen. Mit cout-Debuggen fand ich, dass es sein muss in der Schleife.

Als Nächstes wollte ich wissen, wie weit in die Schleife der segfault passiert, so fügte ich hinzu:

std::cout << i << '\n';

Er zeigte die ganze Palette es war wohl zu Durchlaufen und es war kein segfault.

Mit ein wenig mehr Experimentieren habe ich schließlich erstellt ein string-stream, bevor die Schleife ein und schreiben Sie eine leere Zeichenfolge in die für jede iteration der Schleife und es ist kein segfault.

Habe ich versucht einige verschiedene andere Operationen, um herauszufinden, was Los ist. Ich habe versucht, eine variable j = i; und solches Zeug, aber ich habe nicht gefunden was funktioniert.

Läuft valgrind die einzige information, die ich bekam, an den segfault war, dass es eine "Allgemeine Schutzverletzung" und etwas über Standard-Antwort zu 11. Es erwähnt auch, dass es ein Bedingter Sprung oder Bewegung hängt nicht initialisierten Wert(en), aber ein Blick in den code habe ich nicht herausfinden können, wie das möglich ist.

Was kann das sein? Ich bin aus Ideen zu erkunden.

  • Was sagt der debugger genau? Wie Sie wissen, der block ist groß genug? Wie wurde es verteilt? Könnte entry_count haben sich seitdem geändert? Warum bist du nicht mit std::vector?
  • Wir müssen sehen, mehr code. Vorausgesetzt int* memory = new int[entry_count], dann sollte alles OK sein. Oder laden Sie die core - Datei im gdb und zeige uns die Ausgabe von where und bt full. Schließlich sollten Sie verwenden new oder besser std::vector.
  • Nichts in dem code, den Sie zur Verfügung gestellt sollte mal ein segfault, wenn Ihre Annahmen über memory korrekt sind. Ich schlage vor, mit std::vector welche Grenzen geprüft auf gute debug-Compiler und wahrscheinlich zeigen Sie Ihr problem sofort.
  • Gibt es überhaupt einen Grund für die Verwendung von raw-Pointer zu speichern, ein array?
  • Wenn Sie schreiben eine low-level-memory-management-system.
  • Nicht gering-Ebene bedeuten nur C und nicht C++, und daher std::vector nicht zur Verfügung stehen?
  • Nein, wie C++ und C sind verschiedene Sprachen, und diese Frage ist über C++.
  • Der erste Schritt ist, Aussagen wie "ich weiß, dass dieser block ist groß genug", und werfen Sie Sie Weg.
  • Der exakt gleiche code funktioniert unter windows. Ich weiß, dass es groß genug ist, weil mit den exakt gleichen Werten in den Variablen, die in Gespräche, um die Zuordnung, sah ich auf dem Speicher in Visual Studio, und es passt.
  • Sie haben möglicherweise nicht definiertes Verhalten in anderen code, wodurch es zum auftreten dieser code.
  • Rollback; es ist grob falsch, aber es gibt keinen Grund, Sauer auf die Menschen, die Sie sind, um Hilfe zu bitten.
  • The same exact code works under windows. Was bedeutet, dass absolut nichts in der Welt von C++. Sie haben memory-Korruption, es gibt keine Garantie, wie Sie Ihr Programm ausgeführt wird.
  • Ich verstehe, dass. Der Punkt ist, dass ich weiß, dass bei diesem test Fall der Speicherblock, der groß genug ist. Es sei denn, der Unix-Zuweisung gerne mal weniger Speicher als die Sie sich wünschen.
  • Sie haben beschädigte Arbeitsspeicher, Zeitraum. Wenn das passiert, werfen alle Ihre Erwartungen aus dem Fenster.
  • Okay, in diesem Fall, was in der Regel verursacht eine Speicherbeschädigung auf Unix, die nicht zu einer Speicherbeschädigung auf windows?
  • C++ hat eine Bedingung genannt undefined behavior. Das bedeutet, dass der Speicher beschädigt werden, kann alles passieren. Es ist keine Antwort auf deine Frage, außer, dass Sie schrieb schlechten code, und undefinierten Verhalten getreten. Sie können schreiben, ein buggy Programm für Windows, das kann oder kann nicht auf der gleichen Maschine laufen.
  • In der Praxis, was dazu neigt, arbeiten in der cl-compiler, der nicht auf g++ 4.8 können, verursachen eine Allgemeine Schutzverletzung?
  • Es gibt keine "tendiert zu arbeiten". Entweder es ist gültig code oder es ist es nicht. Wenn nicht, dann sind alle Wetten ab.
  • Dann erklären Sie mir, warum das gleiche passiert mit jedem Lauf? Ich weiß, in der Theorie land "alles KANN passieren", aber in der realen Welt gibt es wirklich eine bestimmte Sache, die nicht passieren. Also, wenn Sie nicht wissen, dann teilen, sonst weiß man einfach nicht.
  • Ändern der compiler-Optionen und was wird dann die Erklärung sein, wenn deine Windows-version plötzlich abstürzt? Sie versuchen zu erklären, zu undefiniertem Verhalten entspricht ein Hund jagt seinen Schwanz.
  • Der Punkt ist, ich bin versucht, das problem zu finden, und es wäre schön zu wissen, was ich Suche. Ich weiß nicht viel über Unix, also ich Frage, ob jemand mir sagen kann, was ich Suche.
  • Dies ist der Grund, warum andere zu Ihnen erwähnt über die intelligente Zeiger, Vektoren, etc. Es gibt einen Punkt, wo es schwierig wird, wenn nicht fast unmöglich zu erkennen, wo der code nicht zur Laufzeit. Es kann ein zig Gründe für ein Programm nicht -- Misswirtschaft der Zeiger, dynamischer Speicher, oder einfach nur falsch C++ - Programmierung, die nur passiert, um nicht zu scheitern, die ganze Zeit (Rückgabe von Zeigern auf lokale Variablen, zum Beispiel).

InformationsquelleAutor | 2015-03-29
  1. 3

    Dies ist eindeutig ein Symptome von ungültigen Speicher verwendet in Ihrem Programm.Das wäre etwas schwierig zu finden, durch Ihr code-snippet ein, als es ist, wahrscheinlich die Nebenwirkung von etwas anderem ist schlecht, das ist bereits geschehen.

    Jedoch als Sie haben in Ihrer Frage erwähnt, dass Sie in der Lage, schließen Sie Ihr Programm mit Valgrind. wie ist es reproduzierbare. So können Sie befestigen Sie Ihr Programm(ein.out).

    $ valgrind --tool=memcheck --db-attach=yes ./ein.aus

    Diese Weise Valgrind würden befestigen Ihr Programm in den debugger, wenn Sie Ihre erste Speicher-Fehler, so dass Sie tun können live-debugging(GDB). Dies sollte die bestmögliche Art und Weise zu verstehen und zu lösen Ihr problem.

    Sobald Sie in der Lage, um es herauszufinden, Ihre ersten Fehler zu beheben und es erneut und sehen, was sind die anderen Fehler, die Sie bekommen.Diese Schritte sollten durchgeführt werden, bis kein Fehler gemeldet abrufen von Valgrind.

    Jedoch sollten Sie vermeiden, mit der raw-Pointer in der modernen C++ - Programme, und starten Sie mit std::vector std::unique_ptr wie vorgeschlagen, die von anderen als gut.

    InformationsquelleAutor Mantosh Kumar
  2. 2

    Valgrind und GDB sind sehr nützlich.

    Den meisten vorherigen, die ich verwendet wurde, GDB - ich mag es, weil es mir zeigte, die genaue Zeilennummer, die der Segmentation Fault auf.

    Hier sind einige Ressourcen, die Ihnen helfen können, die auf die Verwendung des GDB:

    GDB Tutorial 1

    GDB Tutorial 2

    Wenn Sie immer noch nicht herausfinden, wie den Gebrauch von GDB mit diesen tutorials gibt es massenweise bei Google! Suchen Sie einfach Debuggen speicherzugriffsverletzungen mit GDB!

    Glück 🙂

    InformationsquelleAutor Tman
  3. 0

    Dass ist schwer, ich benutzt valgrind tools zum Debuggen seg-Fehler und in der Regel spitz zu Verletzungen.

    Wahrscheinlich, dass dein problem ist, befreit den Speicher, den Sie zu schreiben sind, d.h. sorted_array wird out-of-scope oder wird befreit.
    Hinzufügen mehr code verbirgt sich das problem, wie die Daten Zuweisung Schichten rund um.

    • Haben Sie memgrind mit bounds-check? Memcheck Memcheck erkennt Speicher-management-Probleme, und richtet sich in Erster Linie an C-und C++ - Programme. Wenn ein Programm ausgeführt unter Memcheck Aufsicht, alle lese-und Schreibvorgänge der Speicher geprüft werden, und Aufrufe von malloc/new/free/delete abgefangen werden. Als Ergebnis, Memcheck erkennen können, ob Ihr Programm ...
    • Ich habe noch nie davon gehört. Ich verwendet, memcheck, dass die einzige option war ich.
    • Es gibt eine Menge von Optionen, Memcheck: a memory error detector. Fand ich --malloc-Füll-und-kostenlos-füllen nützlich. Auch, wenn Sie post von mc berichten, dass würde helfen.
    InformationsquelleAutor iceraj
  4. 0

    Nach ein paar Tagen des Experimentierens, ich habe herausgefunden, was wirklich Los war.

    Aus irgendeinem Grund die Maschine segfaults auf unaligned access. Das heißt, die zahlen, die ich geschrieben hatte wurden nicht geschrieben, um Speicher-Grenzen, die waren ein Vielfaches von vier bytes. Vor der Schleife I berechnet den offset-und verlagert das array so viel:

    int offset = (4 - (uintptr_t)(memory) % 4) % 4;
memory += offset;

    Nachdem ich dies alles verhielt sich wie erwartet wieder.

    InformationsquelleAutor
Schreibe einen Kommentar