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?

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?

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.

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

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.

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?

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.

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.

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_D2gc2gc10numMallocslTmTkTmTxC8TypeInfoZ.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

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_D2gc2gc10numMallocslTmTkTmTxC8TypeInfoZ.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