Comment 3 for bug 1471029

I tried some more things:

1. Compiling with clang makes no difference.

2. Compiling with -fsanitize=address results a "stack overflow" message followed by a stack trace. It doesn't reveal as much as the post-mortum traceback in gdb. The address sanitizer seems to make the error deterministic.

3. Copying the debian/ packaging directory into the git tree and compiling from there makes no difference. Most of the
contents of debian/patches are already upstream anyway.

4. Switching the linker to gold makes no difference.

The process map (from apport-unpack) never lists memory as [stack], and always has a double [heap] listing with a window of 0x1000 in the middle. Like this:

dump9/ProcMaps:b7ccf000-bfabb000 rw-p 00000000 00:00 0 [heap]
dump9/ProcMaps:bfabc000-bfb14000 rw-p 00000000 00:00 0 [heap]

The stack pointer is using the second of these (i.e., in this case bfabc000-bfb14000, and the segfault is when it hits the window. Typically this allows the stack a few hundred kB (352k in the example above).

It looks like something is putting the process's memory together wrongly.