Marcin 'Qrczak' Kowalczyk wrote:
> [...] Now it only sometimes crashes at Ctrl-C. The following progam
> does so too (about 1/10 of runs): [...]

I can't reproduce this. BTW, the foreign object interface will change
in future versions of GHC:

----------------------------------------------------------------
module ForeignObj
        ( ForeignObj,        -- abstract, instance of: Eq
        , makeForeignObj     -- :: Addr -> IO () -> IO ForeignObj
        , foreignObjToAddr   -- :: ForeignObj -> Addr
        ) where ...
----------------------------------------------------------------

I.e. the module name is more consistent, *every* foreign object has
one finalizer, the foreign object is immutable, and foreignObjToAddr
is not in the IO monad any longer. If you use ghc-4.06, you can simply
use the module FFI, which imports Addr/ForeignObj among other things
and offers malloc/free, too:

----------------------------------------------------------------
import FFI
import IO

main:: IO ()
main = do
    hSetBuffering stdout NoBuffering
    sequence_ . repeat $ do
        addr <- malloc 100
        makeForeignObj addr (putStrLn "finalizer" >> free addr)
        putStrLn "x"
----------------------------------------------------------------

But testing this showed another strange phenomenon: The heap grows
infinitely.  :-(  A cut-down version, which has the same effect:

----------------------------------------------------------------
import Addr
import Foreign

main:: IO ()
main = do
   fo <- mkForeignObj nullAddr
   addForeignFinalizer fo (putStrLn "finalizer")
   main
----------------------------------------------------------------

An example run:

----------------------------------------------------------------
panne:/tmp > ./Crash1 +RTS -M40M -Sstderr > /dev/null
Crash1 +RTS -M40M -Sstderr
    Alloc    Collect    Live    GC    GC     TOT     TOT  Page Flts
    bytes     bytes     bytes  user  elap    user    elap
   263168    262144    120532  0.00  0.03    0.00    0.05    6  134  (Gen:  1)
  6355968    385024   8045144  0.08  0.10    0.08    0.16    0    8  (Gen:  0)
   803840   8306688   8340236  0.08  0.09    0.17    0.26    0    0  (Gen:  0)
  3056640   8605696  11735868  0.10  0.13    0.27    0.39    0    0  (Gen:  1)
  2166784   4026368  14311456  0.07  0.07    0.35    0.47    0    0  (Gen:  0)
  2547712   2846720  17382480  0.06  0.06    0.42    0.54    0    0  (Gen:  0)
  2390016   3350528  20249280  0.07  0.08    0.49    0.63    0    0  (Gen:  0)
  2423808  20512768  21617948  0.20  0.26    0.69    0.90    0    0  (Gen:  1)
  2452480   3190784  24565464  0.08  0.08    0.77    0.98    0    0  (Gen:  0)
Heap exhausted;
Current maximum heap size is 39997440 bytes;
use `+RTS -M<size>' to increase it.
----------------------------------------------------------------

Things get even stranger: Replacing `putStrLn "finalizer"' with a
simple `return ()' yields constant space:

----------------------------------------------------------------
panne:/tmp > ./Crash2 +RTS -M200k -Sstderr > /dev/null
Crash2 +RTS -M200k -Sstderr
    Alloc    Collect    Live    GC    GC     TOT     TOT  Page Flts
    bytes     bytes     bytes  user  elap    user    elap
   263168    262144    120532  0.00  0.03    0.00    0.04    7  132  (Gen:  1)
  6355968    385024    120544  0.01  0.01    0.01    0.06    0    5  (Gen:  0)
  6356992    385024    120544  0.01  0.01    0.03    0.08    0    0  (Gen:  0)
  6356992    385024    120544  0.01  0.01    0.04    0.09    0    0  (Gen:  0)
  6356992    385024    120544  0.01  0.01    0.06    0.11    0    0  (Gen:  0)
[... ad infinitum ... ]
----------------------------------------------------------------

Simon: Something wrong with the weak pointer stuff (used for
implementing addForeignFinalizer)?

Puzzled,
   Sven
-- 
Sven Panne                                        Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik                     FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen              Oettingenstr. 67
mailto:[EMAIL PROTECTED]            D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne

Reply via email to