[GHC] #2161: finaliser of a ForeignPtr called while references from unreachable threads exist

GHC trac at galois.com
Mon Mar 17 13:40:13 EDT 2008


#2161: finaliser of a ForeignPtr called while references from unreachable threads
exist
----------------------------+-----------------------------------------------
 Reporter:  agl             |          Owner:                
     Type:  bug             |         Status:  new           
 Priority:  normal          |      Milestone:  _|_           
Component:  Runtime System  |        Version:  6.8.2         
 Severity:  major           |     Resolution:                
 Keywords:                  |     Difficulty:  Unknown       
 Testcase:                  |   Architecture:  x86_64 (amd64)
       Os:  Linux           |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

  * difficulty:  => Unknown
  * summary:  GHC threaded RTS will call the finaliser of a ForeignPtr
              while references still exist => finaliser of a
              ForeignPtr called while references from
              unreachable threads exist
  * milestone:  => _|_

Comment:

 Ok, what's happening here is the thread that has a reference to the
 `ForeignPtr` is itself unreachable, and so the GC considers both the
 thread and the `ForeignPtr` unreachable.  It then sends an exception to
 the thread, and starts the finalizer for the `ForeignPtr` simultaneously.

 This is similar to the case where two finalizers refer to each others'
 `ForeignPtr`s: they can both be invoked simultaneously.

 You may argue that a reference from a thread, even an unreachable one,
 should keep a `ForeignPtr` alive.  But it's equally valid to argue the
 reverse: a reference from a finalizer should keep a thread alive - you
 don't want a thread to be considered deadlocked if it can be unblocked by
 a finalizer.  We can't have both, because then a cycle between a finalizer
 and a thread would never be collected even when both were unreachable.

 OTOH, perhaps this is a case where C finalizers should be treated
 differently from Haskell finalizers.  A weak pointer with a C finalizer
 could be kept alive by an unreachable thread.  I'll leave this bug open to
 remind us if we ever special-case C finalizers (which is probably a good
 idea for other reasons).

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


More information about the Glasgow-haskell-bugs mailing list