This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/24963] deadlock between freopen and fclose


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]