¿Qué es un error de autobús?

¿Qué significa el mensaje “error de bus” y cómo difiere de un segfault?

Hoy en día, los errores de bus son raros en x86 y ocurren cuando su procesador no puede siquiera intentar el acceso a memoria solicitado, típicamente:

  • usando una instrucción de procesador con una dirección que no satisface sus requisitos de alineación.

Las fallas de segmentación ocurren al acceder a la memoria que no pertenece a su proceso, son muy comunes y generalmente son el resultado de:

  • usando un puntero a algo que fue desasignado.
  • usando un puntero falso no inicializado.
  • usando un puntero nulo.
  • desbordando un buffer.

PD: para ser más precisos, esto no está manipulando el puntero mismo que causará problemas, sino que está accediendo a la memoria a la que apunta (desreferenciación).

Un segfault es acceder a la memoria a la que no tiene acceso. Es de solo lectura, no tienes permiso, etc.

Un error de bus está intentando acceder a la memoria que no puede estar allí. Usó una dirección que no tiene sentido para el sistema o el tipo de dirección incorrecto para esa operación.

Creo que el núcleo aumenta SIGBUS cuando una aplicación muestra una desalineación de datos en el bus de datos. Creo que como la mayoría de los comstackdores [?] Modernos para la mayoría de los procesadores completan / alinean los datos para los progtwigdores, los problemas de alineación de antaño (al menos) se mitigaron y, por lo tanto, uno no ve el SIGBUS con demasiada frecuencia (AFAIK).

De: Aquí

mmap minimal POSIX 7 ejemplo

El “error de bus” ocurre cuando el kernel envía un SIGBUS a un proceso.

Un ejemplo mínimo que lo produce porque ftruncate fue olvidado:

 #include  /* O_ constants */ #include  /* ftruncate */ #include  /* 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; } 

Corre con:

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

Probado en Ubuntu 14.04.

POSIX describe SIGBUS como:

Acceso a una parte indefinida de un objeto de memoria.

La especificación mmap dice que:

Las referencias dentro del rango de direcciones que comienzan en pa y continúan por bytes longitudinales a páginas enteras después del final de un objeto darán lugar a la entrega de una señal SIGBUS.

Y shm_open dice que genera objetos de tamaño 0:

El objeto de memoria compartida tiene un tamaño de cero.

Entonces en *map = 0 estamos tocando más allá del final del objeto asignado.

También puede obtener SIGBUS cuando una página de códigos no puede ser localizada por alguna razón.

Depende de su sistema operativo, CPU, comstackdor y posiblemente de otros factores.

En general, significa que el bus de la CPU no pudo completar un comando, o sufrió un conflicto, pero eso podría significar todo un rango de cosas dependiendo del entorno y el código que se está ejecutando.

-Adán

Una instancia clásica de un error de bus está en ciertos arquitectros, como el SPARC (al menos algunos SPARC, tal vez esto ha sido cambiado), es cuando se hace un acceso mal alineado. Por ejemplo:

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

Este fragmento intenta escribir el valor entero de 32 bits 0xdeadf00d en una dirección que (muy probablemente) no está alineada correctamente, y generará un error de bus en architectures que son “quisquillosas” en este aspecto. El Intel x86 no es, por cierto, una architecture así, permitiría el acceso (aunque lo ejecutaría más lentamente).

Obtenía un error de bus cuando el directorio raíz estaba al 100%.

Por lo general, significa un acceso no alineado.

Un bash de acceder a la memoria que no está físicamente presente también generaría un error de bus, pero no verá esto si está usando un procesador con una MMU y un sistema operativo que no tenga errores, ya que no tendrá ningún error. – memoria existente asignada al espacio de direcciones de su proceso.

Un ejemplo específico de un error de bus que acabo de encontrar al progtwigr C en OS X:

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

En caso de que no recuerde que los documentos strcat anexa el segundo argumento al primero cambiando el primer argumento (voltee los argumentos y funciona bien). En Linux esto produce un error de segmentación (como se esperaba), pero en OS X da un error de bus. ¿Por qué? Realmente no lo sé

El motivo del error de bus en Mac OS X fue que traté de asignar aproximadamente 1Mb en la stack. Esto funcionó bien en un hilo, pero cuando se usa openMP esto conduce al error de bus, porque Mac OS X tiene un tamaño de stack muy limitado para hilos no principales .

Para agregar a lo que blxtd respondió anteriormente, los errores de bus también ocurren cuando su proceso no puede intentar acceder a la memoria de una ‘variable’ en particular .

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

Observe el uso ' inadvertido ' de la variable 'i' en el primer 'for loop'? Eso es lo que está causando el error de bus en este caso.

Acabo de descubrir por las malas que en un procesador ARMv7 puede escribir un código que le da un error de segmentación cuando no se optimiza, pero le da un error de bus cuando se comstack con -O2 (optimice más). Estoy usando gcc arm gnueabihf cross compiler de ubuntu x64.

Un desbordamiento de búfer típico que da como resultado un error de bus es

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

Aquí si el tamaño de la cadena entre comillas dobles (“”) es más que el tamaño buf, da error de bus.

Esto también podría referirse a problemas humanos. En varios campos de investigación (quizás más amplio), el “error de autobús” de jerga tiene un significado diferente, que creo que podría ser una respuesta relevante. Cuando solo hay una persona que sabe cómo hacer algo crucial para un flujo de trabajo particular, y esa persona repentinamente no está disponible ( es decir , “cae bajo un autobús”, pero lo más probable es que sube y baja inesperadamente), esto se conoce como un autobús error. Es tan catastrófico como un error de autobús “real”, ya que sin el conocimiento de esta persona sobre cómo mantener o incluso ejecutar el flujo de trabajo de investigación, todo el sistema se desmorona. Ser vulnerable a los errores de autobús es un signo de mala gestión.

Intereting Posts