Meine Anwendung segfaults manchmal und hauptsächlich in malloc() und malloc_consolidate(), wenn ich mir den Backtrace in gdb ansehe.
Ich habe überprüft, ob der Computer über genügend Speicher verfügt, er hat nicht einmal mit dem Austausch begonnen. Ich habe ulimits auf Datensegment und maximale Speichergröße überprüft und beide sind auf „unbegrenzt“ eingestellt. Ich habe die Anwendung auch unter valgrind ausgeführt und keine Speicherfehler gefunden.
Jetzt habe ich keine Ideen mehr, was diese Segfaults sonst verursachen könnte. Irgendwelche Ideen ?
Aktualisieren:
Da ich mit valgrind (oder ptrcheck) nichts finde, könnte es sein, dass eine andere Anwendung die Speicherstruktur von libc zerstört, oder gibt es für jeden Prozess eine separate Struktur?
Von http://www.gnu.org/s/libc/manual/html_node/Heap-Consistency-Checking.html#Heap-Consistency-Checking:
Eine weitere Möglichkeit, bei der Verwendung von malloc, realloc und free nach Fehlern zu suchen und sich dagegen zu wehren, besteht darin, die Umgebungsvariable MALLOC_CHECK_ zu setzen. Wenn MALLOC_CHECK_ gesetzt ist, wird eine spezielle (weniger effiziente) Implementierung verwendet, die tolerant gegenüber einfachen Fehlern ist, wie z. B. doppelte Aufrufe von free mit demselben Argument oder Überläufe eines einzelnen Bytes (Off-by-One-Bugs). Nicht alle derartigen Fehler können jedoch geschützt werden, und Speicherlecks können die Folge sein. Wenn MALLOC_CHECK_ auf 0 gesetzt ist, wird jede erkannte Heap-Beschädigung stillschweigend ignoriert; wenn auf 1 gesetzt, wird eine Diagnose auf stderr gedruckt; wenn auf 2 gesetzt, wird abort sofort aufgerufen. Dies kann nützlich sein, da es sonst viel später zu einem Absturz kommen kann und die wahre Ursache des Problems dann sehr schwer zu finden ist.
Höchstwahrscheinlich zerstören Sie den Heap – dh Sie schreiben über die Grenzen eines von Ihnen zugewiesenen Speicherbereichs hinaus, und dies überschreibt die Datenstrukturen malloc() verwendet, um den Heap zu verwalten. Dies bewirkt malloc() um auf eine ungültige Adresse zuzugreifen, und Ihre Anwendung stürzt ab.
Das Ausführen von Speicher würde nicht verursachen malloc() abstürzen – es würde einfach zurückkehren NULL. Dies kann dazu führen, dass Ihr Code abstürzt, wenn Sie nicht nach suchen NULLaber die Absturzstelle wäre nicht drin malloc().
Es ist etwas seltsam, dass Valgrind keine Fehler meldet – aber es gibt einige Fehler, die das standardmäßige „Memcheck“-Tool übersehen kann. Versuchen Sie, Valgrid mit dem auszuführen “Ptrcheck”-Tool stattdessen.
Ist es unter Valgrind abgestürzt?
– Douglas Leder
23. Juni 2010 um 9:03 Uhr
Nein, es ist nicht abgestürzt. Es ist eine Echtzeitanwendung und unter Valgrind kann ich sie nur sehr leicht belasten und sie stürzt normalerweise nur unter einer schwereren Last ab.
– Gen Vincent
23. Juni 2010 um 10:18 Uhr
Welches Betriebssystem ist das? Der Toolchain nach zu urteilen, klingt es, als ob es sich um Linux handeln könnte. In diesem Fall nein, andere Anwendungen können Ihren Heap nicht zerstören; es ist etwas in Ihrer Anwendung. Wenn das nur unter Last passiert, wird es natürlich umso kniffliger… Was ist unter Last anders? Wie könnte das dazu führen, dass Sie den Haufen entsorgen? Versuchen Sie, Ihre Anwendung so gut wie möglich zu “quälen”, während sie unter Valgrind läuft … wie können Sie die Bedingungen, die unter Last herrschen würden, am besten reproduzieren? Vielleicht unentgeltlich Speicher zuweisen, so etwas?
–Martin B
23. Juni 2010 um 15:41 Uhr