And I don't use C stuff in the application. I don't explicitly free anything and use the last version of D.

Obviously, the problem isn't easy to reproduce in a small program, But I get consistent crash in some test cases.

So, What am I supposed to do now to investigate the issue ?

On 10/10/2012 9:43 AM, deadalnix wrote:
> And I don't use C stuff in the application. I don't explicitly free anything and
> use the last version of D.
>
> Obviously, the problem isn't easy to reproduce in a small program, But I get
> consistent crash in some test cases.
>
> So, What am I supposed to do now to investigate the issue ?

These kinds of issues can be hard to debug.

First off, this is the first report I've heard in years that the GC is reclaiming live objects. So, my first thought is some other memory corruption is happening in your program.

My second thought is to make sure all the compiler checks are turned on - don't use -release. Try to use @safe.

The gc has several debugging versions you can uncomment. These can generate a blizzard of data, but sometimes that's the last resort.

Make sure you don't have escaping references to a function's stack frame. These aren't detected by the compiler/runtime, and will cause horrible corruption problems.

Compiling and running your program under a different operating system can often flush out corruption problems. Try valgrind on Linux.

Le 11/10/2012 12:39, Walter Bright a écrit :
> On 10/10/2012 9:43 AM, deadalnix wrote:
>> And I don't use C stuff in the application. I don't explicitly free
>> anything and
>> use the last version of D.
>>
>> Obviously, the problem isn't easy to reproduce in a small program, But
>> I get
>> consistent crash in some test cases.
>>
>> So, What am I supposed to do now to investigate the issue ?
>
> These kinds of issues can be hard to debug.
>
> First off, this is the first report I've heard in years that the GC is
> reclaiming live objects. So, my first thought is some other memory
> corruption is happening in your program.
>

Actually, I have a memory corruption. When trying to debug it, I noticed that the if I disable the GC, the memory corruption didn't happened anymore. Some more investigation lead me to conclude that the GC was reclaiming live memory.

This is the first time I notice that, so indeed, I'm as surprised as you.

> My second thought is to make sure all the compiler checks are turned on
> - don't use -release. Try to use @safe.
>
> The gc has several debugging versions you can uncomment. These can
> generate a blizzard of data, but sometimes that's the last resort.
>

I'm currently playing with that.

> Make sure you don't have escaping references to a function's stack
> frame. These aren't detected by the compiler/runtime, and will cause
> horrible corruption problems.
>

Can you elaborate on that ? It may really be the problem as I use closures quite a lot.

I have made some research and found a workaround.

It seems that the problem is somehow related to map.array combination, but couldn't reproduce it on a simple test case.

Alex Rønne Petterson think to think that it is related to this bug http://d.puremagic.com/issues/show_bug.cgi?id=8774 (and it is possible, however hard to tell if it is really the case).

Replacing several map.array by foreach loops solved the issue. My best guess is that the frame pointer is passed in some way that the GC is not aware of.

What can I do now to help identifying the issue more precisely ?