digitalmars.D.learn - Problem using shared D library from C shared library
- Yuxuan Shui (19/19) Apr 06 2016 I have a D shared library which is loaded by a C shared library,
- rikki cattermole (2/22) Apr 06 2016 Have you started D's runtime?
- Yuxuan Shui (4/7) Apr 06 2016 How to start D's runtime? I followed the examples found here:
- Mike Parker (12/21) Apr 06 2016 The runtime is needed if you are going to use any of its
- Yuxuan Shui (3/16) Apr 06 2016 Thanks a lot.
- Yuxuan Shui (2/15) Apr 06 2016 static this/static ~this should work, right?
- rikki cattermole (2/19) Apr 06 2016 They execute when the runtime is started.
- Yuxuan Shui (4/10) Apr 06 2016 So now I add call rt_init in the C shared library. Now the D
- Yuxuan Shui (19/31) Apr 06 2016 Back trace:
- Yuxuan Shui (3/35) Apr 06 2016 Looks like _d_arrayappendcTX asked for a enormous amount of
- Yuxuan Shui (4/8) Apr 06 2016 Just find out it's my own fault.
- jkpl (2/11) Apr 06 2016 right, that's why it's annotated @nogc ;)
- rikki cattermole (2/11) Apr 06 2016 Unless you add it, no.
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
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
On Thursday, 7 April 2016 at 01:42:54 UTC, rikki cattermole wrote:On 07/04/2016 1:38 PM, Yuxuan Shui wrote: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.[...]Have you started D's runtime?
Apr 06 2016
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: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.On 07/04/2016 1:38 PM, Yuxuan Shui wrote: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.[...]Have you started D's runtime?
Apr 06 2016
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:Thanks a lot. I wish this can be better documented, though.[...]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
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:static this/static ~this should work, right?[...]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
On 07/04/2016 3:18 PM, Yuxuan Shui wrote:On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:They execute when the runtime is started.On Thursday, 7 April 2016 at 01:50:31 UTC, Yuxuan Shui wrote:static this/static ~this should work, right?[...]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
On Thursday, 7 April 2016 at 03:19:58 UTC, rikki cattermole wrote:On 07/04/2016 3:18 PM, Yuxuan Shui wrote: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.On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:They execute when the runtime is started.[...]static this/static ~this should work, right?
Apr 06 2016
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: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.70On 07/04/2016 3:18 PM, Yuxuan Shui wrote: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.On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:They execute when the runtime is started.[...]static this/static ~this should work, right?
Apr 06 2016
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:Looks like _d_arrayappendcTX asked for a enormous amount of memory and it fails, can't figure out whyOn Thursday, 7 April 2016 at 03:19:58 UTC, rikki cattermole wrote: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.70On 07/04/2016 3:18 PM, Yuxuan Shui wrote: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.On Thursday, 7 April 2016 at 02:01:31 UTC, Mike Parker wrote:They execute when the runtime is started.[...]static this/static ~this should work, right?
Apr 06 2016
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:Just find out it's my own fault. BTW, memory block allocated by core.stdc.stdlib.malloc will not be scanned by collector, right?[...]Looks like _d_arrayappendcTX asked for a enormous amount of memory and it fails, can't figure out why
Apr 06 2016
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:right, that's why it's annotated nogc ;)On Thursday, 7 April 2016 at 04:24:48 UTC, Yuxuan Shui wrote:Just find out it's my own fault. BTW, memory block allocated by core.stdc.stdlib.malloc will not be scanned by collector, right?[...]Looks like _d_arrayappendcTX asked for a enormous amount of memory and it fails, can't figure out why
Apr 06 2016
On 07/04/2016 5:23 PM, Yuxuan Shui wrote:On Thursday, 7 April 2016 at 04:36:02 UTC, Yuxuan Shui wrote:Unless you add it, no.On Thursday, 7 April 2016 at 04:24:48 UTC, Yuxuan Shui wrote:Just find out it's my own fault. BTW, memory block allocated by core.stdc.stdlib.malloc will not be scanned by collector, right?[...]Looks like _d_arrayappendcTX asked for a enormous amount of memory and it fails, can't figure out why
Apr 06 2016