Какая ошибка?

segfault обращается к памяти, к которой вам не разрешен доступ. Это только для чтения, у вас нет разрешения и т. д...

ошибка шины пытается получить доступ к памяти,которая не может быть там. Вы использовали адрес, который не имеет смысла для системы, или неправильный адрес для этой операции.

Я считаю, что ядро поднимает SIGBUS когда приложение отображает данные несоосность на шине данных. Я думаю что с тех пор большинство[?] современный компилятор для большинства процессоров pad / align the данные для программистов, проблемы выравнивания былых (по крайней мере) смягчается, а значит никто не видит Платформе ARM слишком часто в эти дни (насколько мне известно).

от: здесь

mmap минимальный пример POSIX 7

"ошибка шины" происходит, когда ядро отправляет SIGBUS для процесса.

минимальный пример, который производит его, так как ftruncate была забыта:

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

запустить с:

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

протестировано в Ubuntu 14.04.

POSIX описаниеSIGBUS как:

доступ к неопределенной части объекта памяти.

в mmap spec говорит, что:

ссылки в диапазоне адресов, начиная с pa и продолжая для байтов len на целые страницы после окончания объекта, должны приводить к доставке сигнала SIGBUS.

и shm_openговорит, что он генерирует объекты размером 0:

объект общей памяти имеет нулевой размер.

так *map = 0 мы касаемся мимо конца выделенные объекты.

вы также можете получить SIGBUS, когда кодовая страница не может быть выгружена по какой-либо причине.

Это зависит от вашей ОС, процессора, компилятора и, возможно, других факторов.

в целом это означает, что шина процессора не смогла выполнить команду или пострадала от конфликта, но это может означать целый ряд вещей в зависимости от среды и выполняемого кода.

Адам

один классический экземпляр ошибки шины находится на определенных архитектурах, таких как SPARC (по крайней мере, некоторые SPARCs, возможно, это было изменено), когда вы делаете неверно выровненный доступ. Например:

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

этот фрагмент пытается записать 32-разрядное целое значение 0xdeadf00d к адресу, который (скорее всего) не выровнен должным образом, и будет генерировать ошибку шины на архитектурах, которые являются "придирчивыми" в этом отношении. Intel x86-это, кстати,не такой архитектура, это позволит получить доступ (хотя и выполнять его медленнее).

Я получал ошибку шины, когда корневой каталог был на 100%.

обычно это означает не выровненный доступ.

попытка доступа к памяти, которая физически не присутствует, также приведет к ошибке шины, но вы не увидите этого, если используете процессор с MMU и ОС, которая не является багги, потому что у вас не будет никакой несуществующей памяти, сопоставленной с адресным пространством вашего процесса.

конкретный пример ошибки шины, с которой я только что столкнулся при программировании C на OS X:

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

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

в случае, если вы не помните, документы strcat добавляет второй аргумент к первому, изменяя первый аргумент (переверните Аргументы, и он отлично работает). В linux это дает ошибку сегментации (как и ожидалось), но в OS X это дает ошибку шины. Зачем? Я действительно не знаю.

моя причина ошибки шины на Mac OS X заключалась в том, что я пытался выделить около 1 Мб в стеке. Это хорошо работало в одном потоке, но при использовании openMP это приводит к ошибке шины, потому что Mac OS X имеет очень ограниченный размер стека для неосновных потоков.

чтобы добавить к тому, что blxtd Ответил выше, ошибки шины также возникают, когда ваш процесс не удается получить доступ к памяти конкретной 'переменной'.

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

обратите внимание на 'непреднамеренное о переменной 'i' на первый 'цикл'? вот что вызывает ошибку шины в этом случае.

Я только что узнал, что на процессоре ARMv7 вы можете написать некоторый код, который дает вам ошибку сегментации при неоптимизации, но дает вам ошибку шины при компиляции с-O2 (оптимизировать больше). Я использую GCC arm gnueabihf cross compiler из ubuntu x64.

типичное переполнение буфера, которое приводит к ошибке шины,

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

здесь, если размер строки в двойных кавычках ("") больше размера buf, это дает ошибку шины.

Это может относиться и к человеческим проблемам тоже. В различных областях исследований (возможно, более широких) сленг "ошибка шины" имеет другое значение, которое, я думаю, может быть уместным ответом. Когда есть только один человек, который знает, как сделать что-то важное для конкретного рабочего процесса, и этот человек внезапно становится недоступным (т. е., "попадает под автобус" - но, скорее всего, просто поднимается и уходит неожиданно), это называется ошибкой шины. Это так же катастрофично, как и" настоящий " автобус ошибка, так как без знания этого человека о том, как поддерживать или даже выполнять рабочий процесс исследования, вся система разваливается. Уязвимость к ошибкам шины является признаком плохого управления.