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

../nptl/pthread_mutex_lock.c:66

gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8T
peInfoZ.runLocked() () from
/var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

/var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

/var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

/var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

/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

 ../nptl/pthread_mutex_lock.c:66

 gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8TypeInfoZ.runLocked()
 () from /var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

 /var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

 /var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

 /var/services/homes/.../install/linux/lib64/libphobos2.so.0.70

 /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.
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.
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.
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.
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 /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8T peInfoZ.runLocked() () from /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 /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 /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8T peInfoZ.runLocked() () from /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 /lib64/libphobos2.so.0.70 /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