fclose blocks until a fread call in another thread returns

[Mike Frysinger]

On 19 Sep 2014 12:51, Mildred Ki'Lya wrote:
> 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.

i would suspect lua is the issue here.  if you could produce a program in C that 
reproduced the problem, that would help us a lot though ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-help/attachments/20150307/884b3375/attachment.sig>