https://issues.dlang.org/show_bug.cgi?id=14444
Issue ID: 14444 Summary: Segfault in GC.malloc Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: mkline.o...@gmail.com I'm working with a coworker on a small utility that involves building an HTML report of differences in ELF files. We are accomplishing this in part with ddmp (https://github.com/francais01/ddmp). Suffice to say that lots of dynamic arrays are involved. I was doing some minor refactoring and changed something that looked like foreach (line; aPipe.byLine) { // Several line.idup calls to get strings } to the more efficient foreach (line; aPipe.byLineCopy) { // No more need for .idup to get strings } Much to my dismay, the program started segfaulting. I fired up GDB and got the following trace: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7459e7e in __memset_avx2 () from /usr/lib/libc.so.6 (gdb) where #0 0x00007ffff7459e7e in __memset_avx2 () from /usr/lib/libc.so.6 #1 0x00000000005d3ef9 in gc.gc.GC.malloc(ulong, uint, ulong*, const(TypeInfo)) (this=0x8568a0 <gc.proxy._gc>, ti=0x82aa70 <TypeInfo_AS4ddmp4diff4Diff.init$>, alloc_size=0x7fffffffcb90, bits=8, size=82673) at src/gc/gc.d:459 #2 0x00000000005a671d in gc_qalloc (__HID12=0x7fffffffcbf8, sz=82673, ba=8, ti=0x82aa70 <TypeInfo_AS4ddmp4diff4Diff.init$>) at src/gc/proxy.d:196 #3 0x00000000005a4d2f in core.memory.GC.qalloc(ulong, uint, const(TypeInfo)) (__HID2=0x7fffffffcc68, ti=0x82aa70 <TypeInfo_AS4ddmp4diff4Diff.init$>, ba=8, sz=82673) at src/core/memory.d:368 #4 0x00000000005dbc78 in rt.lifetime.__arrayAlloc(ulong, const(TypeInfo), const(TypeInfo)) (__HID15=0x7fffffffcd20, tinext=0x82a9e0 <TypeInfo_S4ddmp4diff4Diff.init$>, ti=0x82aa70 <TypeInfo_AS4ddmp4diff4Diff.init$>, arrsize=82656) at src/rt/lifetime.d:441 #5 0x00000000005aaec5 in _d_arraycatnTX (ti=0x82aa70 <TypeInfo_AS4ddmp4diff4Diff.init$>, arrs=...) at src/rt/lifetime.d:2206 #6 0x0000000000597b20 in ddmp.util.insert!(ddmp.diff.Diff).insert(ref ddmp.diff.Diff[], long, ddmp.diff.Diff[]) (stuff=..., i=2821, array=0x7fffffffd1d0) at ddmp/source/ddmp/util.d:47 ... The code in frame 6 is just a simple concatenation of a dynamic array and two slices of another: void insert(T)( ref T[] array, long i, T[] stuff) { assert(i <= array.length); array = array[0..i] ~ stuff ~ array[i..$]; } I started digging into the garbage collector, but somewhat unsurprisingly, it is a complex and stateful beast, so I wasn't able to make much headway in the limited time I have at work. You'll notice the segfault takes place on the memset in GC.malloc, so one could only assume that the garbage collector thinks it has some memory it doesn't and blows up when trying to write over it. Attempts to learn more using valgrind were hampered by lots of alerts coming from the GC such as small invalid reads and conditional jumps or moves depending on uninitialized variables. (This is also concerning.) If there is some way I can produce a dump of the GC heap or any other useful data, please let me know. We're on dmd 2.067 using different flavors of Linux (Arch and OpenSUSE 13.2), FWIW. --