Bug 4185 – Existence of an empty, uncalled function that takes a TLS variable as its parameter generates segfaulting executable using DMD >= 2.044 and the GOLD linker.

void* bar; void foo(void*) {} void baz() { foo(bar); } void main() {} This code causes DMD to produce an executable that segfaults inside of GC.collect. (gdb) bt #0 0x08050aa2 in _D4core6thread17thread_suspendAllUZv7suspendMFC4core6thread6ThreadZv () #1 0x08050a1b in thread_suspendAll () #2 0x0804decd in _D2gc3gcx3Gcx11fullcollectMFPvZk () #3 0x0804deae in _D2gc3gcx3Gcx16fullcollectshellMFZk () #4 0x0804d115 in _D2gc3gcx2GC18fullCollectNoStackMFZv () #5 0x0804bd20 in gc_term () #6 0x0804a9b0 in _D2rt6dmain24mainUiPPaZi6runAllMFZv () #7 0x0804a8b9 in _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv () #8 0x0804a868 in main () However, in the course of boiling down a test case, the segfault has moved around with great regularity (inside of a library SO, inside of libc.exit, whilst appending to an array, the list goes on), so I'm speculating that it's some kind of memory corruption. This occurs on Linux using D2, neither D1 nor Windows using D1,D2 manifests this issue.

I forgot to say that this issue occurs when using DMD 2.044 and up.

If bar is declared as __gshared, the executable behaves correctly.

I can't reproduce this on Linux 2.045 and the current beta. Can you try a clean install of the compiler?

Yep. What arch are you on? How much memory do you have installed (myself == x86, 1.5 GiB). Like I said, I think this is memory corruption of some description, so it's bound to be nebulous.

I'm on x86 1 Gb. What flags do you pass to the compiler?

None: dmd testmodule

Steve, could you run it in valgrind?

Steven, sorry. :o

Okay, this only occurs when the GNU GOLD linker is installed instead of the vanilla. This could be a bug in DMD, but it's probably GOLD, so closing this as INVALID.