Am 26.09.2017 um 21:59 schrieb Mengu:
hi all
i have a long running process in my vibe.d app (as a command line option - vibe is not even started). i don't know why and how vibe interferes with it but i get the following segfault (on freebsd) and the errors i get is becoming so annoying, i'm going to port my program to another language.
#0 0x0000000000aff7bf in vibe.core.driver.deleteEventDriver() () at ../../../../home/search-master/.dub/packages/vibe-d-0.8.1/vibe-d/core/vibe/core/driver.d:54 54 s_driver.dispose(); [Current thread is 1 (LWP 100738)] (gdb) bt full #0 0x0000000000aff7bf in vibe.core.driver.deleteEventDriver() () at ../../../../home/search-master/.dub/packages/vibe-d-0.8.1/vibe-d/core/vibe/core/driver.d:54 (...) Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
It looks like something may be going wrong with thread-local storage. At
least I don't see a high-level explanation for the error when looking at
the code (which is pretty isolated from other side effects). The problem
is that the global TLS variable s_driver seemingly contains garbage
when the thread is being teared down and the module destructor gets called.
Can you try if this also happens with LDC or vice-versa? If not, that
would support the TLS assumption.
I can sympathize with you regarding such errors, they tend to be really
annoying and expensive in terms of development time loss. But on the
positive side, these things have gotten a lot less frequent in the
recent years, since a rigorous regression test policy has been
implemented. The important part is getting them reported on
issues.dlang.org with a test case and ideally flagging them as a
regression if they are - then they tend to get fixed very quickly and
are more or less guaranteed to never come back.
My personal pain point that remains though is Optlink on Windows, which
is not as well maintained as DMD itself and has some nasty bugs that I
currently can't even find workarounds for.