On Tuesday, 22 July 2014 at 17:59:02 UTC, Daniel Murphy wrote:
>
> I'm hoping I can get the GC's memstomp/sentinel to find it, although that might not work if it's a bug in the GC itself.
>
> My other option is fixing my execution trace debugger (seems to get lost inside a system dll) and spend a few days tracing backwards from the segfault.

I'm wondering if the issue is related with the use of extern(C++) classes.
It seems to consistently crash at the same place, which seems to be a virtual function call.

Is there anything special about allocation of C++ classes?

"safety0ff"  wrote in message news:dzdiqnunamteyjcdcljn@forum.dlang.org...

> I'm wondering if the issue is related with the use of extern(C++) classes.

Haha well it could be.  This is the first project to use them after all.

> It seems to consistently crash at the same place, which seems to be a virtual function call.

It does?  It seems every time I add/remove a debugging printf it changes position.

> Is there anything special about allocation of C++ classes?

They're allocated without the finalize bit set, unlike normal classes.  And they have their own member alignment rules and different vtable layout. 

On Wednesday, 23 July 2014 at 21:51:34 UTC, safety0ff wrote:
>
> It seems to consistently crash at the same place, which seems to be a virtual function call.
>

The consistency was likely due to running inside the debugger.

I tried looking a little deeper into this today, looks like the GC is collecting live objects.
The reason it keeps crashing in virtual dispatches is because when the GC places the free block into a list, it stomps on the vtable pointer (this is my working theory.) I'll rebuild to get the line numbers within druntime to have more confidence that this is what is happening.

On Tuesday, 22 July 2014 at 15:07:14 UTC, Daniel Murphy wrote:
> "Daniel Murphy"  wrote in message news:lqlugc$7l7$1@digitalmars.com...
>
> I don't know why enabling the GC makes it crash.

I think I found one reason: aav.* allows storing references to GC objects in the C/C++ heap.

On Saturday, 26 July 2014 at 01:07:43 UTC, safety0ff wrote:
>
> I think I found one reason: aav.* allows storing references to GC objects in the C/C++ heap.

Yup! I converted aav.c into d by hand and now I can compile hello world with GC enabled.

I also found some temporary allocations in the auto-ported files that I changed to use root.rmem module.

We should check the other C++ sources to make sure they don't store references to GC objects, but this was a good first step.

> Of the failing platforms:
> OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is crazy)
...

So, this is fixed now, right?

On Thursday, 25 September 2014 at 17:06:48 UTC, Tourist wrote:
>> Of the failing platforms:
>> OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is crazy)
> ...
>
> So, this is fixed now, right?

Yep.

https://github.com/D-Programming-Language/dmd/pull/3970

"Tourist"  wrote in message news:ekvdxwosqarmsnkhkqle@forum.dlang.org... 

> > Of the failing platforms:
> > OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is crazy)
> ...
> 
> So, this is fixed now, right?

Yep.

https://auto-tester.puremagic.com/?projectid=10

Just windows left now.

On Friday, 26 September 2014 at 03:55:38 UTC, Daniel Murphy wrote:
> "Tourist"  wrote in message news:ekvdxwosqarmsnkhkqle@forum.dlang.org...
>
>> > Of the failing platforms:
>> > OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is crazy)
>> ...
>> 
>> So, this is fixed now, right?
>
> Yep.
>
> https://auto-tester.puremagic.com/?projectid=10
>
> Just windows left now.

Cool. Is there an open ticket for Windows?

"Tourist"  wrote in message news:ccumfjjyzzjvlfjmyfbg@forum.dlang.org... 

> > Just windows left now.
> 
> Cool. Is there an open ticket for Windows?

Nope.