[Issue 14444] New: Segfault in GC.malloc
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Mon Apr 13 15:42:37 PDT 2015
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 at puremagic.com
Reporter: mkline.on.d at 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.
--
More information about the Digitalmars-d-bugs
mailing list