GC allocation issue

[Etienne Cimon]

On 2014-03-20 21:46, Etienne Cimon wrote:
> On 2014-03-20 21:08, Adam D. Ruppe wrote:
>> On Friday, 21 March 2014 at 00:56:22 UTC, Etienne wrote:
>>> I tried using emplace but the copy gets deleted by the GC. Any idea why?
>>
>> That's extremely unlikely, the GC doesn't know how to free manually
>> allocated things. Are you sure that's where the crash happens?
>>
>> Taking a really quick look at your code, this line raises a red flag:
>> https://github.com/globecsys/cache.d/blob/master/chd/table.d#L55
>>
>> Class destructors in D aren't allowed to reference GC allocated memory
>> through their members. Accessing that string in the dtor could be a
>> problem that goes away with GC.disable too.
>
> Yes, you're right I may have a lack of understanding about destructors,
> I'll review this. I managed to generate a VisualD projet and the
> debugger confirms the program crashes on the GC b/c it has a random call
> stack for everything under fullcollect().
>
>       cache-d_d.exe!gc at gc@Gcx at mark
()    C++
>       cache-d_d.exe!gc at gc@Gcx at fullcollect
()    C++
>  >
> cache-d_d.exe!std at array@Appender!string at Appender@ensureAddable(unsigned
> int this) Line 2389    C++
>       [External Code]
>
> cache-d_d.exe!std at array@Appender!string at Appender@ensureAddable(unsigned
> int this) Line 2383    C++
> ....
>
>
> I have no methodology for debugging under these circumstances, do you
> know of anything else I can do than manually review the pathways in the
> source code?

It seems to be crashing somewhere here in druntime's gc.d :

     void mark(void *pbot, void *ptop, int nRecurse)
     {
         //import core.stdc.stdio;printf("nRecurse = %d\n", nRecurse);
         void **p1 = cast(void **)pbot;
         void **p2 = cast(void **)ptop;

Considering it's an access violation of a root that was probably added 
by phobos, could this be an issue with these libraries?