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.
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é. –
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? –
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