www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Problem using shared D library from C shared library

reply Yuxuan Shui <yshuiv7 gmail.com> writes:
I have a D shared library which is loaded by a C shared library, 
which is in turn loaded by my main program.

When the D library tries to allocate something, the whole program 
get an SIGSEGV in __GI___pthread_mutex_lock.

Stack trace:

(gdb) bt
#0  __GI___pthread_mutex_lock (mutex=0x7fffffffc1b8) at 
../nptl/pthread_mutex_lock.c:66
#1  0x00007fffe19cbeef in 
gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8T
peInfoZ.runLocked() () from
/var/services/homes/.../install/linux/lib64/libphobos2.so.0.70
#2  0x00007fffe19c4f66 in gc.gc.GC.malloc() () from 
/var/services/homes/.../install/linux/lib64/libphobos2.so.0.70
#3  0x00007fffe19cda18 in gc_qalloc () from 
/var/services/homes/.../install/linux/lib64/libphobos2.so.0.70
#4  0x00007fffe19e17dd in rt.lifetime.__arrayAlloc() () from 
/var/services/homes/.../install/linux/lib64/libphobos2.so.0.70
#5  0x00007fffe19e6d26 in _d_arrayliteralTX () from 
/var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

What can be the problem?
Apr 06 2016
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 07/04/2016 1:38 PM, Yuxuan Shui wrote:
 I have a D shared library which is loaded by a C shared library, which
 is in turn loaded by my main program.

 When the D library tries to allocate something, the whole program get an
 SIGSEGV in __GI___pthread_mutex_lock.

 Stack trace:

 (gdb) bt
 #0  __GI___pthread_mutex_lock (mutex=0x7fffffffc1b8) at
 ../nptl/pthread_mutex_lock.c:66
 #1  0x00007fffe19cbeef in
 gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8TypeInfoZ.runLocked()
 () from /var/services/homes/.../install/linux/lib64/libphobos2.so.0.70
 #2  0x00007fffe19c4f66 in gc.gc.GC.malloc() () from
 /var/services/homes/.../install/linux/lib64/libphobos2.so.0.70
 #3  0x00007fffe19cda18 in gc_qalloc () from
 /var/services/homes/.../install/linux/lib64/libphobos2.so.0.70
 #4  0x00007fffe19e17dd in rt.lifetime.__arrayAlloc() () from
 /var/services/homes/.../install/linux/lib64/libphobos2.so.0.70
 #5  0x00007fffe19e6d26 in _d_arrayliteralTX () from
 /var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

 What can be the problem?
Have you started D's runtime?
Apr 06 2016
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 7 April 2016 at 01:42:54 UTC, rikki cattermole wrote:
 On 07/04/2016 1:38 PM, Yuxuan Shui wrote:
 [...]
Have you started D's runtime?
How to start D's runtime? I followed the examples found here: https://dlang.org/dll-linux.html#dso9, which doesn't say anything about starting the runtime.
Apr 06 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 7 April 2016 at 01:50:31 UTC, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 01:42:54 UTC, rikki cattermole 
 wrote:
 On 07/04/2016 1:38 PM, Yuxuan Shui wrote:
 [...]
Have you started D's runtime?
How to start D's runtime? I followed the examples found here: https://dlang.org/dll-linux.html#dso9, which doesn't say anything about starting the runtime.
The runtime is needed if you are going to use any of its features, like the GC. If you restrict yourself strictly to C in D (and that means avoiding thinks like builtin AAs, array concatenation, and anything that touches the runtime) you can do without it. The functions you want are core.runtime.rt_init for initialization and core.runtime.rt_term for cleanup [1]. On Windows, you can guarantee these will be called by adding a DLLMain checking for DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH. On other platforms, you'll need to work out something else. [1] http://dlang.org/phobos/core_runtime.html#.rt_init
Apr 06 2016
next sibling parent Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:
 On Thursday, 7 April 2016 at 01:50:31 UTC, Yuxuan Shui wrote:
 [...]
The runtime is needed if you are going to use any of its features, like the GC. If you restrict yourself strictly to C in D (and that means avoiding thinks like builtin AAs, array concatenation, and anything that touches the runtime) you can do without it. The functions you want are core.runtime.rt_init for initialization and core.runtime.rt_term for cleanup [1]. On Windows, you can guarantee these will be called by adding a DLLMain checking for DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH. On other platforms, you'll need to work out something else. [1] http://dlang.org/phobos/core_runtime.html#.rt_init
Thanks a lot. I wish this can be better documented, though.
Apr 06 2016
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:
 On Thursday, 7 April 2016 at 01:50:31 UTC, Yuxuan Shui wrote:
 [...]
The runtime is needed if you are going to use any of its features, like the GC. If you restrict yourself strictly to C in D (and that means avoiding thinks like builtin AAs, array concatenation, and anything that touches the runtime) you can do without it. The functions you want are core.runtime.rt_init for initialization and core.runtime.rt_term for cleanup [1]. On Windows, you can guarantee these will be called by adding a DLLMain checking for DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH. On other platforms, you'll need to work out something else. [1] http://dlang.org/phobos/core_runtime.html#.rt_init
static this/static ~this should work, right?
Apr 06 2016
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 07/04/2016 3:18 PM, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:
 On Thursday, 7 April 2016 at 01:50:31 UTC, Yuxuan Shui wrote:
 [...]
The runtime is needed if you are going to use any of its features, like the GC. If you restrict yourself strictly to C in D (and that means avoiding thinks like builtin AAs, array concatenation, and anything that touches the runtime) you can do without it. The functions you want are core.runtime.rt_init for initialization and core.runtime.rt_term for cleanup [1]. On Windows, you can guarantee these will be called by adding a DLLMain checking for DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH. On other platforms, you'll need to work out something else. [1] http://dlang.org/phobos/core_runtime.html#.rt_init
static this/static ~this should work, right?
They execute when the runtime is started.
Apr 06 2016
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 7 April 2016 at 03:19:58 UTC, rikki cattermole wrote:
 On 07/04/2016 3:18 PM, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:
 [...]
static this/static ~this should work, right?
They execute when the runtime is started.
So now I add call rt_init in the C shared library. Now the D library no longer gets SIGSEGV, but throws no memory exception when it tries to allocate.
Apr 06 2016
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 7 April 2016 at 03:37:39 UTC, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 03:19:58 UTC, rikki cattermole 
 wrote:
 On 07/04/2016 3:18 PM, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:
 [...]
static this/static ~this should work, right?
They execute when the runtime is started.
So now I add call rt_init in the C shared library. Now the D library no longer gets SIGSEGV, but throws no memory exception when it tries to allocate.
Back trace: (gdb) bt #0 0x00007fffe19e006c in _d_throwdwarf () from /lib64/libphobos2.so.0.70 #1 0x00007fffe19af2ab in onOutOfMemoryErrorNoGC () from /lib64/libphobos2.so.0.70 #2 0x00007fffe19cbfa3 in gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8T peInfoZ.runLocked() () from /lib64/libphobos2.so.0.70 #3 0x00007fffe19c4f66 in gc.gc.GC.malloc() () from /lib64/libphobos2.so.0.70 #4 0x00007fffe19cda18 in gc_qalloc () from /lib64/libphobos2.so.0.70 #5 0x00007fffe19e17dd in rt.lifetime.__arrayAlloc() () from /lib64/libphobos2.so.0.70 #6 0x00007fffe19e6445 in _d_arrayappendcTX () from /lib64/libphobos2.so.0.70 #7 0x00007fffe19e5b47 in _d_arrayappendT () from /lib64/libphobos2.so.0.70
Apr 06 2016
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 7 April 2016 at 04:24:48 UTC, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 03:37:39 UTC, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 03:19:58 UTC, rikki cattermole 
 wrote:
 On 07/04/2016 3:18 PM, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:
 [...]
static this/static ~this should work, right?
They execute when the runtime is started.
So now I add call rt_init in the C shared library. Now the D library no longer gets SIGSEGV, but throws no memory exception when it tries to allocate.
Back trace: (gdb) bt #0 0x00007fffe19e006c in _d_throwdwarf () from /lib64/libphobos2.so.0.70 #1 0x00007fffe19af2ab in onOutOfMemoryErrorNoGC () from /lib64/libphobos2.so.0.70 #2 0x00007fffe19cbfa3 in gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8T peInfoZ.runLocked() () from /lib64/libphobos2.so.0.70 #3 0x00007fffe19c4f66 in gc.gc.GC.malloc() () from /lib64/libphobos2.so.0.70 #4 0x00007fffe19cda18 in gc_qalloc () from /lib64/libphobos2.so.0.70 #5 0x00007fffe19e17dd in rt.lifetime.__arrayAlloc() () from /lib64/libphobos2.so.0.70 #6 0x00007fffe19e6445 in _d_arrayappendcTX () from /lib64/libphobos2.so.0.70 #7 0x00007fffe19e5b47 in _d_arrayappendT () from /lib64/libphobos2.so.0.70
Looks like _d_arrayappendcTX asked for a enormous amount of memory and it fails, can't figure out why
Apr 06 2016
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Thursday, 7 April 2016 at 04:36:02 UTC, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 04:24:48 UTC, Yuxuan Shui wrote:
 [...]
Looks like _d_arrayappendcTX asked for a enormous amount of memory and it fails, can't figure out why
Just find out it's my own fault. BTW, memory block allocated by core.stdc.stdlib.malloc will not be scanned by collector, right?
Apr 06 2016
next sibling parent jkpl <jkpl nowhere.de> writes:
On Thursday, 7 April 2016 at 05:23:47 UTC, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 04:36:02 UTC, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 04:24:48 UTC, Yuxuan Shui wrote:
 [...]
Looks like _d_arrayappendcTX asked for a enormous amount of memory and it fails, can't figure out why
Just find out it's my own fault. BTW, memory block allocated by core.stdc.stdlib.malloc will not be scanned by collector, right?
right, that's why it's annotated nogc ;)
Apr 06 2016
prev sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 07/04/2016 5:23 PM, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 04:36:02 UTC, Yuxuan Shui wrote:
 On Thursday, 7 April 2016 at 04:24:48 UTC, Yuxuan Shui wrote:
 [...]
Looks like _d_arrayappendcTX asked for a enormous amount of memory and it fails, can't figure out why
Just find out it's my own fault. BTW, memory block allocated by core.stdc.stdlib.malloc will not be scanned by collector, right?
Unless you add it, no.
Apr 06 2016