Workaround for typeid access violation

[rsw0x via Digitalmars-d]

On Tuesday, 16 June 2015 at 14:00:55 UTC, Etienne wrote:
> There is a bug regarding unordered object collection in the GC. 
> My finalizer accesses another GC-allocated object and the 
> application *sometimes* crashes here:
>
> void _d_invariant(Object o)
> {   ClassInfo c;
>
>     //printf("__d_invariant(%p)\n", o);
>
>     // BUG: needs to be filename/line of caller, not library 
> routine
>     assert(o !is null); // just do null check, not invariant 
> check
>
>     c = typeid(o);
>
>         ^--------- this is the crash location
>
> The culprit seems to be these operations:
>
> 00007ff6`881f324b 488b4510        mov     rax,qword ptr 
> [rbp+10h]
> 00007ff6`881f324f 488b10          mov     rdx,qword ptr [rax]
> 00007ff6`881f3252 488b1a          mov     rbx,qword ptr [rdx] 
> ds:00000000`00000000=????????????????
>
> The vtable lookup wants to dereference a null entry. Not sure 
> how I can fix this, but in the meantime I think typeid could 
> actually add a small check on RDX and return null if that's 
> what it is. Any input?

This is undefined behavior, the only solution is "don't do it"
see my thread
http://forum.dlang.org/post/vcpcjujvkbuoswyzycat@forum.dlang.org

destructors as they are shouldn't exist at all, they are 
incredibly bug prone.

Bye.