Was ist ein Busfehler? Unterscheidet es sich von einem Segmentierungsfehler?

Question 1

Was bedeutet die Meldung „Busfehler“ und wie unterscheidet sie sich von a Segmentierungsfehler?

Question 2

Busfehler sind heutzutage auf x86 selten und treten auf, wenn Ihr Prozessor den angeforderten Speicherzugriff nicht einmal versuchen kann, typischerweise:

Verwenden einer Prozessoranweisung mit einer Adresse, die ihre Ausrichtungsanforderungen nicht erfüllt.

Segmentierungsfehler treten auf, wenn auf Speicher zugegriffen wird, der nicht zu Ihrem Prozess gehört. Sie sind sehr häufig und sind typischerweise das Ergebnis von:

Verwenden eines Zeigers auf etwas, das freigegeben wurde.
Verwenden eines nicht initialisierten, daher falschen Zeigers.
mit einem Nullzeiger.

Überlaufen eines Puffers.

PS: Genauer gesagt, es ist nicht die Manipulation des Zeigers selbst, die Probleme verursachen wird. Es greift auf den Speicher zu, auf den es zeigt (Dereferenzierung).

Question 3

Ein Segfault greift auf Speicher zu, auf den Sie nicht zugreifen dürfen. Es ist schreibgeschützt, Sie haben keine Berechtigung usw.

Ein Busfehler versucht, auf Speicher zuzugreifen, der unmöglich dort sein kann. Sie haben eine Adresse verwendet, die für das System bedeutungslos ist, oder die falsche Art von Adresse für diesen Vorgang.

Question 4

mmap minimales POSIX 7-Beispiel

“Bus error” tritt auf, wenn der Kernel sendet SIGBUS zu einem Prozess.

Ein Minimalbeispiel, das es denn hergibt ftruncate wurde vergessen:

#include <fcntl.h> /* O_ constants */
#include <unistd.h> /* ftruncate */
#include <sys/mman.h> /* mmap */

int main() {
    int fd;
    int *map;
    int size = sizeof(int);
    char *name = "/a";

    shm_unlink(name);
    fd = shm_open(name, O_RDWR | O_CREAT, (mode_t)0600);
    /* THIS is the cause of the problem. */
    /*ftruncate(fd, size);*/
    map = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    /* This is what generates the SIGBUS. */
    *map = 0;
}

Laufen mit:

gcc -std=c99 main.c -lrt
./a.out

Getestet unter Ubuntu 14.04.

Posix beschreibt SIGBUS wie:

Zugriff auf einen undefinierten Teil eines Speicherobjekts.

Das mmap spez sagt, dass:

Verweise innerhalb des Adressbereichs beginnend bei pa und weiter für len Bytes auf ganze Seiten nach dem Ende eines Objekts führen zur Lieferung eines SIGBUS-Signals.

Und shm_open sagt, dass es erzeugt Objekte der Größe 0:

Das gemeinsam genutzte Speicherobjekt hat eine Größe von Null.

Also bei *map = 0 wir berühren das Ende des zugewiesenen Objekts.

Nicht ausgerichtete Stapelspeicherzugriffe in ARMv8 aarch64

Dies wurde erwähnt bei: Was ist ein Busfehler? für SPARC, aber hier werde ich ein besser reproduzierbares Beispiel liefern.

Alles, was Sie brauchen, ist ein freistehendes aarch64-Programm:

.global _start
_start:
asm_main_after_prologue:
    /* misalign the stack out of 16-bit boundary */
    add sp, sp, #-4
    /* access the stack */
    ldr w0, [sp]

    /* exit syscall in case SIGBUS does not happen */
    mov x0, 0
    mov x8, 93
    svc 0

Dieses Programm wirft dann SIGBUS auf Ubuntu 18.04 aarch64, Linux-Kernel 4.15.0 in ein ThunderX2-Servermaschine.

Leider kann ich es im Benutzermodus von QEMU v4.0.0 nicht reproduzieren, ich bin mir nicht sicher warum.

Der Fehler scheint optional zu sein und wird von der gesteuert SCTLR_ELx.SA und SCTLR_EL1.SA0 Felder habe ich die zugehörigen Dokumente zusammengefasst hier etwas weiter.

Question 5

Ich glaube, der Kernel löst SIGBUS aus, wenn eine Anwendung eine Datenfehlausrichtung auf dem Datenbus aufweist. Ich denke das seit den meisten[?] Moderne Compiler für die meisten Prozessoren füllen / richten die Daten für die Programmierer aus, die Alignment-Probleme von früher (zumindest) gemildert, und daher sieht man SIGBUS heutzutage nicht mehr allzu oft (AFAIK).

Aus: Hier

Question 6

An Posix Systemen können Sie das SIGBUS-Signal auch erhalten, wenn eine Codepage aus irgendeinem Grund nicht eingeblättert werden kann.

Question 7

Ich stimme allen obigen Antworten zu. Hier sind meine 2 Cent zum BUS-Fehler:

Ein BUS-Fehler muss nicht von den Anweisungen innerhalb des Programmcodes herrühren. Dies kann passieren, wenn Sie eine Binärdatei ausführen und während der Ausführung die Binärdatei geändert wird (durch einen Build überschrieben oder gelöscht usw.).

Überprüfen, ob dies der Fall ist

Eine einfache Möglichkeit, zu überprüfen, ob dies die Ursache ist, besteht darin, ein paar Instanzen derselben Binärdatei aus einem Build-Ausgabeverzeichnis zu starten und nach dem Start einen Build auszuführen. Beide laufenden Instanzen würden mit a abstürzen SIGBUS Fehler kurz nachdem der Build abgeschlossen ist und die Binärdatei ersetzt hat (diejenige, die beide Instanzen derzeit ausführen).

Zugrunde liegender Grund

Dies liegt daran, dass das Betriebssystem Speicherseiten austauscht und in einigen Fällen die Binärdatei möglicherweise nicht vollständig in den Speicher geladen wird. Diese Abstürze treten auf, wenn das Betriebssystem versucht, die nächste Seite aus derselben Binärdatei abzurufen, die Binärdatei jedoch seit dem letzten Lesen geändert wurde.

Question 8

Eine klassische Instanz eines Busfehlers tritt auf bestimmten Architekturen auf, wie z SPARC (zumindest einige SPARCs, vielleicht wurde dies geändert), wenn Sie einen falsch ausgerichteten Zugriff vornehmen. Zum Beispiel:

unsigned char data[6];
(unsigned int *) (data + 2) = 0xdeadf00d;

Dieses Snippet versucht, den 32-Bit-Ganzzahlwert zu schreiben 0xdeadf00d an eine Adresse, die (höchstwahrscheinlich) nicht richtig ausgerichtet ist, und erzeugt einen Busfehler auf Architekturen, die in dieser Hinsicht “wählerisch” sind. Der Intel x86 ist übrigens nicht so eine Architektur. Es würde den Zugriff erlauben (wenn auch langsamer ausführen).