Hi Alastair,
> My program is a compiler. It does a lot of allocation (and,
> hence, GC).
> Towards the end of compilation, it calls a greencarded
> library to solve a graph
> problem. This generates a fairly large number of foreign
> pointers (over 2000)
> most of which become free at about the same time. Sometime
> after the freeing
> starts and immediately after a garbage collection, the free
> routine is called
> with a bogus pointer as an argument.
Hmm. How bogus? Is it an address that has been freed twice, or does it
just look like junk?
> Building with ghc-4.07 (built some months ago from the
> repository) instead I
> don't see this problem.
Does it go away/change in 4.08.1 if you adjust the heap size?
> The bug could be in my code but the dependence on compiler
> version suggests
> that GHC could be to blame. Here's a few guesses as to what
> could be going
> wrong:
>
> 1) What happens if a GC occurs while running the finaliser thread?
> This seems a bit tricky so I'm a little suspicious.
The way finalizers are run changed since 4.08.1. In 4.08.1, each finalizer
gets its own thread. Doing a GC at any point while finalizers are running
is safe (they're just normal threads).
In the CVS HEAD, finalizers are batched after each GC, and a single thread
is created to run the batch. The batch of finalizers is placed in an array
before creating the thread; a GC can't happen during this process.
> 2) What happens if a GC occurs whilst preparing the thread
> that calls the
> finalisers?
It can't; see above.
> It looks like it allocates an array, allocates a thread,
> pushes a closure on
> the thread and schedules the thread. Handling a GC during
> this time sounds
> really, really tricky so I'm very suspicious.
This is in the new code, not the 4.08.1 code. In any case, the code you're
referring to is all in C, so it can't get a GC while it's setting up the
thread. But perhaps I'm missing the point: what's tricky about it?
> 3) Some code that manipulates weak pointers could be confusing things.
> Less likely since you'd expect problems to show up fairly quickly.
>
> Well, that's all I could think of. Let me know if you think
> any of these are
> at all likely. I'll whack on this some more tomorrow if I
> don't have to go
> skiing instead.
There is a bug in 4.08.1 related to ForeignObjs spotted by Sigbjorn
recently: if you use writeForeignObj at any point, the finalizer won't see
the changed value when it runs. Could this be affecting you?
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
