[GHC] #7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x

[GHC]

#7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x
---------------------+------------------------------------------------------
Reporter:  cjwatson  |          Owner:                
    Type:  bug       |         Status:  new           
Priority:  normal    |      Component:  Runtime System
 Version:  7.6.3     |       Keywords:                
      Os:  Linux     |   Architecture:  Other         
 Failure:  Other     |      Blockedby:                
Blocking:            |        Related:                
---------------------+------------------------------------------------------
 On Debian's s390x architecture (64-bit S/390, Linux kernel), builds of
 several packages hang with GHC 7.6 where they did not hang with GHC 7.4.
 In particular, ghc itself hangs during its own build when bootstrapping
 with 7.6.  This is quite easy to reproduce on affected systems, although
 it doesn't hang in exactly the same place every time.  It appears that the
 runtime sometimes deadlocks when a subprocess exits; the strace looks like
 this:

 {{{
 7523  exit_group(0)                     = ?
 6680  <... futex resumed> )             = ? ERESTARTSYS (To be restarted)
 6680  --- SIGCHLD (Child exited) @ 0 (0) ---
 6680  futex(0x84fa86ac, FUTEX_WAIT_PRIVATE, 1143, NULL) = ? ERESTARTSYS
 (To be restarted)
 6680  --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
 6680  sigreturn()                       = ? (mask now [])
 6680  futex(0x84fa86ac, FUTEX_WAIT_PRIVATE, 1143, NULL) = ? ERESTARTSYS
 (To be restarted)
 6680  --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
 6680  sigreturn()                       = ? (mask now [])
 6680  futex(0x84fa86ac, FUTEX_WAIT_PRIVATE, 1143, NULL) = ? ERESTARTSYS
 (To be restarted)
 [repeats forever]
 }}}

 ghc spawns enough subprocesses (gcc etc.) that it's essentially bound to
 hit this sooner or later.  I suspect perhaps a lack of signal-safety
 somewhere - at an extremely wild guess, perhaps the type of an important
 variable written in a signal handler happens to exceed the size of
 sig_atomic_t on s390x and not elsewhere - but I haven't yet been able to
 track this down in the time available to me.

 If you don't immediately recognise this as something obvious, then perhaps
 somebody more fluent in Haskell than I would be good enough to suggest
 test code that exercises this and is somewhat simpler than "build ghc"?
 If my analysis is at all close to the mark, then something that sits in a
 loop forking and reaping a trivial child process on each iteration should
 be enough to reproduce this.  On the assumption that most non-Debian-
 developers don't have convenient access to S/390 machines (Debian
 developers can use zelenka.debian.org), I'd be happy to try things out.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7993>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler