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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1471029

Title:
  Segfault in xsltproc on i386

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1471029/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to