error accessing file pointer in a multi-threaded program

error accessing file pointer in a multi-threaded program

What I want to ask is part of some big code but I will try to make it as short as possible. I will first explain the relevant code snippets from my code first and then the error I am getting.

From main.c inside main function:

cilk_for ( line_count = 0; line_count != no_of_lines ; ++line_count )
//some stuff here
for ( j=line_count+1; 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 function from bloom-filter.c file:

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 );
printf ( "Could not open file\\n" );
return count;

bf_dup_eleminate_read from bloom-filter.c file:

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

for CILK_NWORKERS=1 the program runs fine but when I do CILK_NWORKERS=2 it gives error.

This is a multi-threaded application (I ran it by enforcing it to use two threads) and I can be sure that the first thread reaches the printf statement(as it is outputted with thread information). Now gdb tells me that you have the following error

0x0000000000406fc4 in bf_dup_eleminate_read (bf=,
j=) at bloom-filter.c:536

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

The error message is pretty clear but I didnt get that why is it happening. I cannot think of a reason why this is happening. It is sure that the file opened (as error message in function `bf_dup_eleminate` was not printed). Also I have a believe that if two thread are executing same lines of code than they will have separate instantiations for all local variables. Given that what can be the problem.

Any help is appreciated!!

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

If your application runs correctly with 1 work and fails with 2, you probably have a race. Try running your program under the Cilkscreen Race Detector. It's part of the Intel Cilk Plus SDK, which you canget at theIntel Cilk Plus SDK Download Page.

- Barry

I try to use it but my project has muliple files and it is not reporting the race condition in other files with proper annotation (like it is talking only in terms of memory addresses). I tried to use the memory address but with GDB but it didn't work whcih means that I just can't know where the race conditions are. The output of cilkscreen is like

Race condition on location 0x7f2b212dda68
write access at 0x7f2b20fa0207: (_IO_un_link+0x167)
write access at 0x7f2b20fa0368: (_IO_link_in+0x78)
called by 0x7f2b212f79bf: (__cilk_spawn_006+0x7f)
called by 0x7f2b212f7cc6: (cilk_for_recursive+0x286)
called by 0x7f2b212f7daf: (__cilk_spawn_005+0x6f)
called by 0x7f2b212f8216: (cilk_for_root+0x3e6)
called by 0x4033a1: (main+0x1b8d)

Can you help me decode it atleast because neither does it state which line number nor it says which function. I saw the documentation in dod folder and the sample output there is quite different form this.

The compiler takes the body of your cilk_for loop and creates a lambda function from it. In place of the cilk_for loop, it inserts a call into the Cilk runtime which willuses a divide and conqueur algorithm to execute your loop in parallel.

This is saying that you have a race writing to memory in your cilk_for loop body.

If you've compiled your application with debugging information (use -ggdb with ICC or GCC) Cilkscreen should be able to tell you the line numbers for the problem. You should also try disabling all optimization using -O0.

- Barry

Leave a Comment

Please sign in to add a comment. Not a member? Join today