This is the mail archive of the glibc-bugs@sources.redhat.com 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/859] New: When running under SCHED_FIFO, fork + malloc = infinite loop


We have software that runs under SCHED_FIFO; if one of the threads
calls fork() while another thread wants to malloc(), the mallocing
thread gets stuck in an infinite loop.  Some backtraces:

The mallocing thread:

(gdb) bt
#0  0x4019bc7d in pthread_mutex_trylock () from /lib/i686/libpthread.so.0
#1  0x42079dd9 in arena_get2 () from /lib/i686/libc.so.6
#2  0x4207bc95 in calloc () from /lib/i686/libc.so.6

The forking thread:

(gdb) bt
#0  0x4207977e in ptmalloc_lock_all () from /lib/i686/libc.so.6
#1  0x4019c4d2 in fork () from /lib/i686/libpthread.so.0

As far as I can tell, the forking thread locks all the mutexes, then
a context switch is allowed (to let the newly forked process run,
I suppose?), then when a thread from the forking process is next allowed to
run, a thread other than the forking thread happens to be chosen.  And
that thread runs into the following comment from arena.c:

  /* if not even the list_lock can be obtained, try again.  this can
     happen during `atfork', or for example on systems where thread
     creation makes it temporarily impossible to obtain _any_
     locks. */

And, in SCHED_FIFO mode, no context switch can happen while trying
again, so it locks up.

Obviously using SCHED_FIFO is a delicate area, but this still seems
unfortunate.  Any suggestions for ways to work around this?  (I guess
I could modify the code in malloc to do a sched_yield if it goes through
that loop too many times.)  Do newer glibc versions exhibit the same
behavior?  (We'll upgrade to a newer glibc in a few months, I hope.)

-- 
           Summary: When running under SCHED_FIFO, fork + malloc = infinite
                    loop
           Product: glibc
           Version: 2.2.5
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: david dot carlton at sun dot com
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://sources.redhat.com/bugzilla/show_bug.cgi?id=859

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


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