hardcore gdc problems

Sean Kelly sean at f4.ca
Wed Apr 11 15:15:27 PDT 2007


Downs wrote:
> Brad Roberts wrote:
>> Downs wrote:
>>> Downs wrote:
>>>> Update!
>>>
>>> Nevermind this please.
>>> It turned out to be an unrelated bug in the GC.
>>
>> Bug in the GC or bug in your app?  If it's a bug in the GC, please 
>> narrow down the repro case as narrowly as possible and file it in 
>> bugzilla.  If it's in your app, sharing the details of what was wrong 
>> and how you narrowed it down might help others avoid the problem or 
>> track down something similar in the future.
>>
>> Later,
>> Brad
> Thanks for your answer.
> I think it was a bug in the GC, but I'm not sure.
> Reducing it to a testcase might be hard though, since it only happens 
> sporadically in multithreaded mode, so the causes are hard to pin down.
> Be that as it may, since setV1_0 made it go away, I'm labelling it "case 
> closed".
> Please understand that I'm simply unwilling to spend any more time (and 
> nerves) on something which has ceased (finally) to be a problem for me.

If setV1_0 fixed this then the problem is most likely with an object 
containing pointers being marked as not containing pointers by the 
runtime.  Post 1.0, the GC won't scan through these blocks and 
referenced data may be prematurely cleaned up.  There were a bunch of 
bugs related to this after 1.0 and I think one or two corner cases may 
still exist.  I would encourage anyone who finds data disappearing on 
them to please report it once they find the time :-)


Sean


More information about the D.gnu mailing list