Re: Segfault with std.variant
Great! Thank you!
Segfault with std.variant
Howdy,
I've just tried out `std.variant` and I've noticed that I can
induce a segfault by having a variant of variants. Should this
work?
```d
import std.stdio;
import std.variant;
void main()
{
Variant variant = Variant([
"one": Variant(1),
"two": Variant(2),
"three": Variant(3)
]);
writefln("Segfault occurs on the next line");
variant["four"] = Variant(4); // Segfault
writefln("This line will not be reached");
}
```
For whatever reason, the `variant["four"] = Variant(4)` line will
fail with a segfault. I'm using LDC2:
```
LDC - the LLVM D compiler (1.31.0):
based on DMD v2.101.2 and LLVM 14.0.3
built with LDC - the LLVM D compiler (1.31.0)
Default target: x86_64-unknown-linux-gnu
Host CPU: ivybridge
```
Re: Aborting from core/sync/mutex.d(147) Error: pthread_mutex_init failed.
On Wednesday, 1 April 2020 at 02:08:09 UTC, mitchell wrote:
Hello,
I've just finished migrating a project from GDC/Makefile to LDC
with dub. The program now compiles and runs, and works fine
until such time as the following error occurs:
Aborting from core/sync/mutex.d(147) Error: pthread_mutex_init
failed.
out of GDB, the whole text is:
Aborting from core/sync/mutex.d(147) Error: pthread_mutex_init
failed.
Thread 1 "squares" received signal SIGABRT, Aborted.
[Switching to Thread 0x774a7580 (LWP 7576)]
__GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or
directory.
and the backtrace is (sorry for info dump):
#0 __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1 0x776eb535 in __GI_abort () at abort.c:79
#2 0x77ac4fa7 in
_D4core8internal5abortQgFNbNiNfMAyaMQemZv ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#3 0x77acd7e3 in core.sync.mutex.Mutex.~this() ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#4 0x77af12ae in rt_finalize2 () from
/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#5 0x77adb7bf in
_D2gc4impl12conservativeQw3Gcx5sweepMFNbZm ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#6 0x77ad89b2 in
_D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#7 0x77ada126 in
_D2gc4impl12conservativeQw3Gcx10smallAllocMFNbhKmkZPv ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#8 0x77ad6c44 in
_D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl () from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#9 0x77ad92df in
_DThn16_2gc4impl12conservativeQw14ConservativeGC6qallocMFNbmkxC8TypeInfoZS4core6memory8BlkInfo_ () from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#10 0x77addbd0 in gc_qalloc () from
/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#11 0x77ac9fb2 in
_D4core6memory2GC6qallocFNaNbmkxC8TypeInfoZSQBqQBo8BlkInfo_ ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#12 0x77af0519 in _d_newarrayU () from
/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#13 0x556b9682 in
_D7squares4core5coord5Coord9adjacentsMxFNdZASQBrQBmQBkQBh
(this=...)
at
/home/mitchell/Apps/D/games/squares/src/squares/core/coord.d:102
There are several frames above #13 here, but #13 is the last
line of "my" code, and the deeper ones (appear?) to be runtime
and phobos stuff.The lines immediately around coord.d:102 are:
Coord[] adjacents() const @property
{
return [ right, up, left, down ]; // line 102
}
which are defined in a struct called "Coord". I suspect that
there isn't something wrong specifically with this line, and
instead something more "amazingly" wrong. Given that this
worked fine with the previous (and older) version of GDC which
I used before my migration, I don't know what could be wrong.
I'm just not entirely certain where to start looking for
problems. If this issue is over-broad, I'm sorry. Elsewhere in
the program, I make use of the core.thread and Thread things,
however that implementation seems fairly straightforward and
fine, and never had issues under the old compiler.
Any and all help is appreciated!
I have (surprisingly) figured out the issue myself. I guess I
didn't think about this before, but the background thread
(elsewhere in the application) keeps a few mutexes such that it
can pass work to the main thread (for changing UI things, and
such) and it appears that after the background task is completed,
there is at least one mutex which was still held in a locked
state. The error arises (as can been seen from the stack trace)
when that mutex is being destructed. As my underlying system is
unix, the pthread object beneath mutex is destroyed, but
according to the documentation
(https://linux.die.net/man/3/pthread_mutex_destroy) destroying a
mutex while it's still locked can cause an error. After I fixed
my implementation to ensure that all mutexes are unlocked on the
appropriate threads before they can be destructed, the issue went
away. Apparently my old compiler either handled that issue for me
automatically, or it just wasn't being detected.
TLDR: pebkac
Aborting from core/sync/mutex.d(147) Error: pthread_mutex_init failed.
Hello,
I've just finished migrating a project from GDC/Makefile to LDC
with dub. The program now compiles and runs, and works fine until
such time as the following error occurs:
Aborting from core/sync/mutex.d(147) Error: pthread_mutex_init
failed.
out of GDB, the whole text is:
Aborting from core/sync/mutex.d(147) Error: pthread_mutex_init
failed.
Thread 1 "squares" received signal SIGABRT, Aborted.
[Switching to Thread 0x774a7580 (LWP 7576)]
__GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
and the backtrace is (sorry for info dump):
#0 __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1 0x776eb535 in __GI_abort () at abort.c:79
#2 0x77ac4fa7 in
_D4core8internal5abortQgFNbNiNfMAyaMQemZv ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#3 0x77acd7e3 in core.sync.mutex.Mutex.~this() ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#4 0x77af12ae in rt_finalize2 () from
/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#5 0x77adb7bf in
_D2gc4impl12conservativeQw3Gcx5sweepMFNbZm ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#6 0x77ad89b2 in
_D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#7 0x77ada126 in
_D2gc4impl12conservativeQw3Gcx10smallAllocMFNbhKmkZPv ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#8 0x77ad6c44 in
_D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl () from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#9 0x77ad92df in
_DThn16_2gc4impl12conservativeQw14ConservativeGC6qallocMFNbmkxC8TypeInfoZS4core6memory8BlkInfo_ () from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#10 0x77addbd0 in gc_qalloc () from
/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#11 0x77ac9fb2 in
_D4core6memory2GC6qallocFNaNbmkxC8TypeInfoZSQBqQBo8BlkInfo_ ()
from /lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#12 0x77af0519 in _d_newarrayU () from
/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.82
#13 0x556b9682 in
_D7squares4core5coord5Coord9adjacentsMxFNdZASQBrQBmQBkQBh
(this=...)
at
/home/mitchell/Apps/D/games/squares/src/squares/core/coord.d:102
There are several frames above #13 here, but #13 is the last line
of "my" code, and the deeper ones (appear?) to be runtime and
phobos stuff.The lines immediately around coord.d:102 are:
Coord[] adjacents() const @property
{
return [ right, up, left, down ]; // line 102
}
which are defined in a struct called "Coord". I suspect that
there isn't something wrong specifically with this line, and
instead something more "amazingly" wrong. Given that this worked
fine with the previous (and older) version of GDC which I used
before my migration, I don't know what could be wrong.
I'm just not entirely certain where to start looking for
problems. If this issue is over-broad, I'm sorry. Elsewhere in
the program, I make use of the core.thread and Thread things,
however that implementation seems fairly straightforward and
fine, and never had issues under the old compiler.
Any and all help is appreciated!
Re: Issues creating a dynamic libary with dub
On Wednesday, 25 March 2020 at 04:04:09 UTC, rikki cattermole wrote: When I see -fPIC I think something is wrong with your compiler+runtime setup. Use -v to see the commands dub is using. This should not be dub related. It seems you're correct. I looked through some of the older projects I've made on this machine (ones where I used make instead of dub), I found that whenever I made a shared library, I always had to revert to using gcc, rather than gdc. I will need to examine my setup. Thank you for the rapid response!
Issues creating a dynamic libary with dub
Hello, I'm having issues creating a dynamic library with dub. The dub config file contains (with the exception of the names and such) only targetType "dynamicLibrary" When I attempt to buld the library, I get: common ~master: building configuration "library"... /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/libgphobos2.a(ascii.o): relocation R_X86_64_32S against `.data' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/5/libgphobos2.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status gdc failed with exit code 1. I've been working with D for quite a while, but I've never really used dub. It looks like dub is attempting to attach phobos to the dynamic link library I'm trying to create. Is there something simple which I'm missing entirely? I would have asked on the dub forums, but they seem to be down right now.
