Bug 8232 – [GC] Segmentation fault in rt_finalize_gc()

Created attachment 1114 Code causing segmentation fault The 42 lines in the attached file cause a segmentation fault, while parsing a larger textual file. For example, I used the following file, but unzipped it first: ftp://ftp.wormbase.org/pub/wormbase/species/m_hapla/gff/m_hapla.current.annotations.gff3.gz Here is what I get in gdb: Program received signal SIGSEGV, Segmentation fault. 0x080a26b0 in rt_finalize_gc () (gdb) where #0 0x080a26b0 in rt_finalize_gc () #1 0x080a1155 in gc.gcx.Gcx.fullcollect() () #2 0x080a0b4e in gc.gcx.Gcx.fullcollectshell() () #3 0x080a04ea in gc.gcx.Gcx.bigAlloc() () #4 0x0809e66e in gc.gcx.GC.mallocNoSync() () #5 0x0809e50f in gc.gcx.GC.malloc() () #6 0x08094e5e in gc_malloc () #7 0x0809638d in _d_newclass () #8 0x080acfb7 in core.runtime.defaultTraceHandler() () #9 0x0809cfc9 in _d_traceContext () #10 0x08095c44 in _d_createTrace () #11 0xbffff21c in ?? () (gdb) The code uses only the safe subset of D, therefore the worst that should happen is an exception. But here I have a segfault. Me and two others were not able to reduce this code further. Small changes make this segfault go away. For example, it occurs only if the array size in the new statement is 8177 or greater. If it's less, there is no segfault. Replacing "line ~= current_chunk[0..newline_index];" with "line = line ~ current_chunk[0..newline_index];" will also make the segfault go away. The segfault occurs in both 32bit and 64bit builds on Linux, using DMD v2.059.

What is the state of this? Can somebody reproduce? (original testcase is unavailable but there are similar files in same folder on the server)

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17243 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB