fclose blocks until a fread call in another thread returns

[Mildred Ki'Lya <mildred-ml at mildred dot fr>]

Hi,

I'm having a problem with glibc 2.20. I have a program with multiple 
threads (two are running when I have the problem). The main thread 
contains an event loop. The other thread is just a popen call to nmap, 
and a read call that blocks until nmap has finished.

On the main thread, at some point, I open a file, write some content, 
and then close the file.

The problem is that the main thread is always blocking until the nmap 
thread finishes reading the popen pipe.

Running the application with gdb, I found the following stack traces:

main thread:

#0  0x00007ffff73d8b2b in __lll_lock_wait_private () from 
/usr/lib/libc.so.6
#1  0x00007ffff7359b25 in __GI__IO_un_link.part.1 () from 
/usr/lib/libc.so.6
#2  0x00007ffff734dad5 in fclose@@GLIBC_2.2.5 () from /usr/lib/libc.so.6

popen thread:

#0  0x00007ffff73bf55d in read () from /usr/lib/libc.so.6
#1  0x00007ffff73596c0 in __GI__IO_file_underflow () from 
/usr/lib/libc.so.6
#2  0x00007ffff735a6ec in __GI__IO_default_xsgetn () from 
/usr/lib/libc.so.6
#3  0x00007ffff734e860 in fread () from /usr/lib/libc.so.6

It seems that fclose is blocking over a mutex, that I supposed has been 
obtained in the popen thread in the fread call. I looked around at the 
glibc code (genops.c and fileops.c) but haven't found anything obvious.

In case that might be relavant, the implementation is in the Lua 
language and threads are managed by lua lanes.

Do you have any idea what's going wrong?

Thank you,

Mildred