• deadalnix (5/5) Oct 10 2012 And I don't use C stuff in the application. I don't explicitly free
• Walter Bright (14/19) Oct 11 2012 These kinds of issues can be hard to debug.
• deadalnix (9/30) Oct 11 2012 Actually, I have a memory corruption. When trying to debug it, I noticed...
• deadalnix (10/10) Oct 12 2012 I have made some research and found a workaround.

deadalnix <deadalnix gmail.com> writes:

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 ?

Walter Bright <newshound2 digitalmars.com> writes:

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.

deadalnix <deadalnix gmail.com> writes:

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.

deadalnix <deadalnix gmail.com> writes:

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 ?