Conversation
Instead of compiling, linking and running the tool each time on-the-fly, thereby also reducing the memory requirements somewhat (no ldmd2 and ldc2 process ancestors anymore).
0ae3820 to
b13b99d
Compare
| static void disableGC() nothrow @nogc | ||
| { | ||
| __gshared string[] disable_options = [ "gcopt=disable:1" ]; | ||
| rt_options = disable_options; |
There was a problem hiding this comment.
this would override other druntime options, right?
There was a problem hiding this comment.
Only if embedded into LDC. Command line options still have higher precedence.
There was a problem hiding this comment.
Yes, and env variables go inbetween priority-wise, the embedded ones here have lowest priority.
Because run.d and tools/paths.d use syntax which is incompatible with ltsmaster...
As prerequisite for all dmd-testsuite tests. Assume the compiler and druntime + Phobos have been built already, thereby preventing to know the exact druntime/Phobos CMake target names *and* not potentially recompiling an outdated compiler and/or libs when running the tests, just like with the previous Makefile approach.
If the GC is enabled (-lowmem), it must know about those Array instances, so that the GC-allocated array of pointers and referenced GC-allocated strings are kept alive.
This is a cherry-pick from dlang/dmd#10752. Rainer has found out that the compiler might crash with a segfault when aborting via exit() upon some compile error, and that this seems to be related to GC worker threads (so only an issue with recent host compilers), spawned because of some module ctors bypassing `root/rmem.d` and using the GC directly, like setting up an associative array in `imphint.d`. He came up with a nice simple solution to this, making sure the GC starts in disabled mode whenever it is initialized.
|
Well, the sporadic but frequent dmd-testsuite issue (run-dmd-testsuite terminated/killed - |
@rainers: I can reproduce the CircleCI issue locally now, by building the shared libs only on Linux and hacking druntime here to use the specified high number of GC threads - then running dmd-testsuite's run.d with env var |
|
A stack trace, The env variable seems to be ignored, so it's spawning 99 GC threads ;) (gdb) info threadsEdit: Ah sry, this may be worthless if the signal is expected; I'll retry with gdb |
|
Well it looks like it's one of the other, non-GC-related worker threads from the default |
|
Maybe |
Environment variable processing has to be enabled via rt_envvars_enabled.
Might be, but I'm no expert on linux. Where does the message Maybe related: dlang/druntime#2813 |
CircleCI output; I don't recall the exact text in my Ubuntu VM.
The
I've quickly checked |
No description provided.