fclose blocks until a fread call in another thread returns
Mildred Ki'Lya
mildred-ml@mildred.fr
Tue Sep 23 23:06:00 GMT 2014
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
More information about the Libc-help
mailing list