2012-07-02 8 views
5

Tengo un programa paralelo que a veces se ejecuta y a veces simplemente da un fallo de segmentación. El ejecutable cuando se fuerza a ejecutar con 3 hilos funciona bien (básicamente también se ejecuta con un solo hilo que es solo serial) pero da un error de segmentación cuando se lo obliga a ejecutar con cualquier otro valor de hilo. Aquí está el panorama:Un caso curioso en la programación en paralelo

De main.c dentro de la función principal:

cilk_for (line_count = 0; line_count != no_of_lines ; ++line_count) 
{ 
    //some stuff here 
    for (j=line_count+1; j<no_of_lines; ++j) 
    { 
     //some stuff here 
     final_result[line_count][j] = bf_dup_eleminate (table_bloom[line_count], file_names[j], j); 
     //some stuff here 
    } 
    //some stuff here 
} 

bf_dup_eleminate función de bloom-filter.c archivo:

int bf_dup_eleminate (const bloom_filter *bf, const char *file_name, int j) 
{ 
    int count=-1; 
    FILE *fp = fopen (file_name, "rb"); 
    if (fp) 
    { 
     count = bf_dup_eleminate_read (bf, fp, j); 
     fclose (fp); 
    } 
    else 
    { 
     printf ("Could not open file\n"); 
    } 
    return count; 
} 

bf_dup_eleminate_read de bloom-filter.c archivo:

int bf_dup_eleminate_read (const bloom_filter *bf, FILE *fp, int j) 
{ 
    //some stuff here 
    printf ("before while loop. j is %d ** workder id: **********%d***********\n", j, __cilkrts_get_worker_number()); 
    while (/*somecondition*/) 
    {/*some stuff*/} 
    //some stuff 
} 

tuve t su error informado de intel inspector es:

ID | Problem       | Sources  
P1 | Unhandled application exception | bloom-filter.c 

y la pila de llamadas es:

exec!bf_dup_eleminate_read - bloom-filter.c:550 
exec!bf_dup_eleminate - bloom-filter.c:653 
exec!__cilk_for_001.10209 - main.c:341 

Del mismo modo gdb también informar del error en el mismo lugar y es:

ahora gdb me dice que usted tiene el siguiente error

0x0000000000406fc4 in bf_dup_eleminate_read (bf=<error reading variable: Cannot access memory at address 0x7ffff7edba58>, fp=<error reading variable: Cannot access memory at address 0x7ffff7edba50>, j=<error reading variable: Cannot access memory at address 0x7ffff7edba4c>) at bloom-filter.c:536

Line 536 es int bf_dup_eleminate_read (const bloom_filter *bf, FILE *fp, int j)

detalles adicionales:

Ahora mi bloomfilter es un structture definido como

struct bloom_filter 
{ 
    int64_t m;  //size of bloom filter. 
    int32_t k;  //number of hash functions. 
    uint8_t *array; 
    int64_t no_of_elements_added; 
    int64_t expected_no_of_elements; 
}; 

y memoria para que se asigna de la siguiente manera:

bloom_filter *bf = (bloom_filter *)malloc(sizeof(bloom_filter)); 
    if (bf != NULL) 
    { 
     bf->m = filter_size*8;  /* Size of bloom filter */ 
     bf->k = num_hashes; 
     bf->expected_no_of_elements = expected_no_of_elements; 
     bf->no_of_elements_added = (int64_t)0; 
     bf->array = (uint8_t *)malloc(filter_size); 
     if (bf->array == NULL) 
     { 
      free(bf); 
      return NULL; 
     } 
    } 

Hay solo una copia de bloom_filter y se supone que cada subproceso tiene acceso lo mismo (ya que no estoy modificando nada solo leyendo).

¿Alguien podría ayudarme? Porque estoy atrapado aquí los últimos 4 días y no puedo pensar en una salida. La peor parte es que se está ejecutando por 3 hilos !!!

Nota: cilk_for es solo una palabra clave para spawn threads en cilk.

+0

parece que tiene un defecto en la asignación de bloom_filter donde, después de realizar el malloc() para bf-> array, está comprobando si hay NULO de bf en lugar de bf-> array. Este no es tu problema, solo algo que noté. –

+0

Admito que fue un error, pero ejecuté el código actualizado y no funcionó. ¿Puede sugerir alguna otra posibilidad para un error de este tipo? –

+0

Aparece por el error que está accediendo a la memoria que no le pertenece. El otro cambio inmediato que haría sería en la instrucción condicional cilk_for(), usaría line_count

Respuesta

8

Cuando un depurador le indica un error como este:

0x0000000000406fc4 in bf_dup_eleminate_read (
    bf=<error reading variable: Cannot access memory at address 0x7ffff7edba58>, 
    fp=<error reading variable: Cannot access memory at address 0x7ffff7edba50>, 
    j=<error reading variable: Cannot access memory at address 0x7ffff7edba4c> 
) at bloom-filter.c:536 

536: int bf_dup_eleminate_read (const bloom_filter *bf, FILE *fp, int j) 

por lo general indica que el código de entrada de la función (llamada la función "prólogo") está fallando. En resumen, su pila se ha corrompido y la CPU está fallando cuando está calculando las direcciones de las tres variables locales y asignándoles espacio en la pila.

Cosas que me gustaría comprobar si hay o tratar de corregir este error (ninguno de los cuales están garantizados para trabajar, y algunos de los cuales se pudo haber tratado ya):

  1. Asegúrese de que no están invadiendo cualquier espacio utilizado por cualquier variable local que haya declarado en otras partes de su programa.

  2. Asegúrese de no escribir en punteros que han sido declarados como variables locales y luego devueltos de una función en otras partes de su programa.

  3. Asegúrese de que cada subproceso tenga suficiente espacio de pila para manejar todas las variables locales que declare. ¿Estás declarando cualquier buffers grandes basados ​​en pila? El tamaño predeterminado de la pila por subproceso depende de la configuración del compilador o, en este caso, de la biblioteca cilk. Intente aumentar el tamaño de pila por subproceso en tiempo de compilación y vea si el bloqueo desaparece.

Con un poco de suerte, uno de los anteriores debería permitirle reducir el origen del problema.

+1

Thax man !! usted es maravilloso. Estuve atrapado aquí los últimos 5 días y lo intenté todo. Aprendí 3 nuevos softwares e hice todo lo que pude pero no sirvió. Fue por el tercer punto y el choque se va ... :). Muchas gracias de nuevo –

+1

@Aman, estaba en una situación similar. aps2012, me has ahorrado muchos minutos de frustración :) mover un par de matrices grandes desde la función local al alcance global solucionó el problema: D. Estaba obteniendo segfaults en la declaración de la función. –

Cuestiones relacionadas