This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/24963] deadlock between freopen and fclose
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 06 Sep 2019 03:09:59 +0000
- Subject: [Bug libc/24963] deadlock between freopen and fclose
- Auto-submitted: auto-generated
- References: <bug-24963-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=24963
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-09-06
CC| |carlos at redhat dot com
Ever confirmed|0 |1
--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
This looks like it real problem.
The bug is likely in _IO_new_fclose.
We should lock fp first, and then with fp acquired lock the whole list.
All threads will try to operate on fp first, wait, and then attempt any more
complex operations on fp next.
e.g.
diff --git a/libio/iofclose.c b/libio/iofclose.c
index 8a80dd0b78..a7c5357944 100644
--- a/libio/iofclose.c
+++ b/libio/iofclose.c
@@ -44,11 +44,12 @@ _IO_new_fclose (FILE *fp)
return _IO_old_fclose (fp);
#endif
+ _IO_acquire_lock (fp);
+
/* First unlink the stream. */
if (fp->_flags & _IO_IS_FILEBUF)
_IO_un_link ((struct _IO_FILE_plus *) fp);
- _IO_acquire_lock (fp);
if (fp->_flags & _IO_IS_FILEBUF)
status = _IO_file_close_it (fp);
else
---
Someone needs to test and review a solution to this problem.
Yisheng are you working on a solution to post to libc-alpha?
--
You are receiving this mail because:
You are on the CC list for the bug.