Greetings

I am calling a D function from an opensource application coded in C/C++. My code crashes, though there is no reason for it to crash. Also when I call my D function from inside D, it does not crash. The D function does not take any arguments, nor does it try to access any variable declared in C/C++. So it seems to me that it is some memory corruption issue.

But since I am not able to reproduce the crash in standalone D code, I am not able to file a bug.

Can someone please guide me how I can debug this further? I have reduced the D code that crashes, but it crashes only when called from the opensource C/C++ application. The C/C++ application is single threaded and therefor gives full control to D function. And then D code runs for some time and crashes thereafter with a segmentation fault. I am pasting the D code below (C++ calls initialize function):

extern(C) void initialize() {
  import core.runtime;
  Runtime.initialize;
  frop();
}

void frop() {
  import core.thread;
  Dynamic obj = new Dynamic;
  for (size_t i; i!=200; ++i) {
    obj.rehash();
  }
  void foo() {
    for (size_t i; i!=200; ++i) {
	import std.stdio;
	writeln(i);
	obj.rehash(); // segfault happens in the second iteration of loop
	obj.proc();
      }
  }
  Thread bar = new Thread(&foo);
  bar.start();
  bar.join();
}

final class Hash {
  private Dynamic[Dynamic] _m_map;
  public void clear() {
    // only static instance of Hash is used
    // no synchronized region required -- but still
    synchronized(this) {
      _m_map = null;
    }
  }
}

class Dynamic {
  void rehash () {
    // only thread local variables no synchronized required -- but still
    synchronized(this) {
      static Hash hash ;
      if(hash is null) hash = new Hash;
      hash.clear();
    }
  }
  void proc () {
    // only stack variables, so no synchronized required -- but still
    synchronized(this) {
      char[] space;
      space.length = 5000;
    }
  }
}




//  Regards
// - Puneet

On Monday, 14 December 2015 at 05:26:52 UTC, Bottled Gin wrote:
> Greetings
>
> I am calling a D function from an opensource application coded in C/C++. My code crashes, though there is no reason for it to crash. Also when I call my D function from inside D, it does not crash. The D function does not take any arguments, nor does it try to access any variable declared in C/C++. So it seems to me that it is some memory corruption issue.
>
> But since I am not able to reproduce the crash in standalone D code, I am not able to file a bug.
>
> Can someone please guide me how I can debug this further? I have reduced the D code that crashes, but it crashes only when called from the opensource C/C++ application. The C/C++ application is single threaded and therefor gives full control to D function. And then D code runs for some time and crashes thereafter with a segmentation fault. I am pasting the D code below (C++ calls initialize function):
>
> extern(C) void initialize() {
>   import core.runtime;
>   Runtime.initialize;
>   frop();
> }
>
> void frop() {
>   import core.thread;
>   Dynamic obj = new Dynamic;
>   for (size_t i; i!=200; ++i) {
>     obj.rehash();
>   }
>   void foo() {
>     for (size_t i; i!=200; ++i) {
> 	import std.stdio;
> 	writeln(i);
> 	obj.rehash(); // segfault happens in the second iteration of loop
> 	obj.proc();
>       }
>   }
>   Thread bar = new Thread(&foo);
>   bar.start();
>   bar.join();
> }
>
> final class Hash {
>   private Dynamic[Dynamic] _m_map;
>   public void clear() {
>     // only static instance of Hash is used
>     // no synchronized region required -- but still
>     synchronized(this) {
>       _m_map = null;
>     }
>   }
> }
>
> class Dynamic {
>   void rehash () {
>     // only thread local variables no synchronized required -- but still
>     synchronized(this) {
>       static Hash hash ;
>       if(hash is null) hash = new Hash;
>       hash.clear();
>     }
>   }
>   void proc () {
>     // only stack variables, so no synchronized required -- but still
>     synchronized(this) {
>       char[] space;
>       space.length = 5000;
>     }
>   }
> }
>
>
>
>
> //  Regards
> // - Puneet

gdb or lldb. Yes, it sucks.