Hi Simon,
> > 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?
It looks like junk. In fact, what should be a pointer comes out as a
small int (0x17).
btw I should have said that while chasing this down, I've changed the
free routines to do nothing - so it's nothing to do with
initialization order or multiple calls to free. I also filled my C
code full of asserts, tagged objects with magic values, etc. so I have
some reason to believe that my C code isn't to blame (though I still
haven't ruled it out completely).
> Does it go away/change in 4.08.1 if you adjust the heap size?
No, I tried various heap-related arguments and see no change. (If I'd
seen more variation, I wouldn't have spent so long checking my own
code.)
> The way finalizers are run changed since 4.08.1.
Was there any change between 4.04 (which I had no problem with) and 4.08.1?
> the code you're referring to is all in C, so it can't get a GC while
> it's setting up the thread.
I guess I was too used to the old runtime where any allocation was a
potential GC point. I'd forgotten that the new runtime did away with
such things.
> But perhaps I'm missing the point: what's tricky about it?
Well thinking about weak pointers, finalisers, etc always made my head
hurt - and having to spawn of threads to run Haskell finalisers
(instead of just calling the C code out of the garbage collector)
seemed to make things even trickier (though vastly more flexible). So
I just assumed it was tricky.
> 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?
Sounds like it could explain my problem (almost).
Except... I don't use writeForeignObj, Greencard doesn't use it (at
least not in this case) and I can't imagine it being used in the
implementation of makeForeignObj or in the code casm generates when
passing a foreign object to C. Ah well, ...
Well, I guess I'm feeling more confident in GHC's runtime. I guess
I'll see if I can fit any more asserts into my code...
--
Alastair
ps The skiing was very nice... Nice bit of back-country to remind me
just how unfit I am these days.
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
