Ce qui est une erreur de bus?

Une erreur de segmentation est l'accès de la mémoire que vous n'êtes pas autorisé à accéder. C'est en lecture seule, vous n'avez pas la permission, etc...

une erreur de bus essaye d'accéder à une mémoire qui ne peut pas être là. Vous avez utilisé une adresse qui n'a aucun sens pour le système, ou le mauvais type d'adresse pour cette opération.

je crois que le noyau soulève SIGBUS quand une application présente des données désalignement sur le bus de données. Je pense que puisque la plupart des[?] compilateurs modernes pour la plupart des processeurs pad / aligner l' les données pour les programmeurs, le des problèmes d'alignement de longue date (au moins) atténué, et c'est pourquoi l'on ne voit pas SIGBUS trop souvent de nos jours (AFAIK).

De: Ici

mmap position minimale 7 exemple

"erreur de Bus" se produit lorsque le noyau envoie SIGBUS à un processus.

un exemple minimal qui le produit parce que ftruncate a été oublié:

#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;
}

Exécuter avec:

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

testé dans Ubuntu 14.04.

POSIX décrit SIGBUS comme:

accès à une partie non définie d'un objet mémoire.

le mmap spec dit que:

les références dans la plage d'adresses commençant par pa et continuant pour les octets len à des pages entières suivant la fin d'un objet doivent entraîner la livraison d'un signal SIGBUS.

et shm_open dit que il génère des objets de taille 0:

l'objet mémoire partagée a une taille de zéro.

ainsi à *map = 0 nous touchons la fin de l'objet alloué.

vous pouvez également obtenir SIGBUS quand une page de code ne peut pas être pagée pour une raison quelconque.

cela dépend de votre OS, CPU, compilateur, et peut-être d'autres facteurs.

en général, cela signifie que le bus CPU ne pouvait pas exécuter une commande, ou a subi un conflit, mais cela pourrait signifier toute une série de choses selon l'environnement et le code exécuté.

- Adam

une instance classique d'une erreur de bus se trouve sur certaines architectures, comme le SPARC (au moins quelques SPARCs, peut-être que cela a été changé), c'est quand vous faites un accès mal aligné. Par exemple:

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

cet extrait tente d'écrire la valeur entière de 32 bits 0xdeadf00d à une adresse qui n'est (très probablement) pas correctement alignée, et générera une erreur de bus sur les architectures qui sont" difficiles " à cet égard. L'Intel x86 est, par le façon, pas une telle architecture, il permettrait l'accès (quoique l'exécuter plus lentement).

j'ai eu une erreur de bus quand le répertoire racine était à 100%.

il s'agit normalement d'un accès non aligné.

une tentative d'accéder à une mémoire qui n'est pas physiquement présente donnerait aussi une erreur de bus, mais vous ne le verrez pas si vous utilisez un processeur avec un MMU et un OS qui n'est pas bogué, parce que vous n'aurez pas de mémoire inexistante mappée à l'espace d'adresse de votre processus.

un exemple spécifique d'erreur de bus que je viens de rencontrer lors de la programmation de C on OS X:

#include <string.h>
#include <stdio.h>

int main(void)
{
    char buffer[120];
    fgets(buffer, sizeof buffer, stdin);
    strcat("foo", buffer);
    return 0;
}

dans le cas où vous ne vous souvenez pas les docs strcat ajoute le deuxième argument au premier en changeant le premier argument(retourner les arguments et il fonctionne très bien). Sur linux, cela donne un défaut de segmentation(comme prévu), mais sur OS X, cela donne une erreur de bus. Pourquoi? Je ne sais vraiment pas.

ma raison pour l'erreur de bus sur Mac OS X était que j'ai essayé d'allouer environ 1 Mo sur la pile. Cela a bien fonctionné dans un thread, mais lors de l'utilisation d'openMP cela conduit à une erreur de bus, parce que Mac OS X a très limité la taille de la pile pour les threads non-principaux .

pour ajouter à ce que blxtd a répondu ci-dessus, des erreurs de bus se produisent également lorsque votre processus ne peut pas tenter d'accéder à la mémoire d'une 'variable' particulière" .

for (j = 0; i < n; j++) {
                for (i =0; i < m; i++) {
                        a[n+1][j] += a[i][j];
                }
        }

Avis par inadvertance " l'utilisation de variable " i " dans le première "pour la boucle"? C'est ce qui cause l'erreur de bus dans ce cas.

je viens de découvrir à la dure que sur un processeur ARMv7 vous pouvez écrire un code qui vous donne un défaut de segmentation quand vous n'êtes pas optimisé, mais vous donne une erreur de bus quand vous êtes compilé avec-O2 (optimiser plus). J'utilise gcc arm gnueabihf cross compiler de ubuntu x64.

un débordement de tampon typique qui entraîne une erreur de Bus est,

{
    char buf[255];
    sprintf(buf,"%s:%s\n", ifname, message);
}

ici si la taille de la chaîne dans les guillemets doubles ("") est plus que la taille de buf il donne l'erreur de bus.

Cela pourrait se référer à des problèmes humains. Dans divers domaines de la recherche (peut-être plus large), l'argot "erreur de bus" a un sens différent, qui je pense pourrait être une réponse pertinente. Quand il n'y a qu'une seule personne qui sait faire quelque chose de crucial pour un flux de travail particulier, et que cette personne devient soudainement indisponible ( i.e. , "tombe sous un bus" - mais très probablement monte et part inopinément), cela est appelé une erreur de bus. Il est tout aussi catastrophique comme une" vraie " erreur de bus, puisque sans la connaissance de cette personne sur la façon de maintenir ou même exécuter le flux de recherche, le système entier tombe en morceaux. Vulnérables aux erreurs de bus est un signe de mauvaise gestion.