www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 14444] New: Segfault in GC.malloc

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: nobody puremagic.com
          Reporter: mkline.on.d 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.

--
Apr 13 2015