Bug#909242: Xvfb: segfaults on mips during gtk+3.0 build-time tests

2018-09-20 Thread Julien Cristau
Keeping cc to debian-mips, adding libunwind maintainer.

On 09/20/2018 10:23 AM, Simon McVittie wrote:
> Package: xvfb
> Version: 2:1.20.1-2
> Severity: important
> X-Debbugs-Cc: debian-m...@lists.debian.org
> User: debian-m...@lists.debian.org
> Usertags: mips
> 
> My recent gtk+3.0 upload to experimental failed many of its build-time
> tests on mips. The tests could not connect to the Xvfb server run by the
> upstream build system, which later crashed with a segmentation fault.
> 
> https://buildd.debian.org/status/fetch.php?pkg=gtk%2B3.0&arch=mips&ver=3.24.1-1&stamp=1537406479&file=log
> 
> I can reproduce this reliably on the mips porterbox, minkus, by running
> Xvfb in a schroot with the options shown below.
> 
Looking at this with libunwind8-dbgsym installed...

> Core was generated by `Xvfb -ac -noreset -screen 0 1024x768x16 :1 -nolisten 
> tcp -auth /dev/null'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
> (gdb) bt
> #0  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
> #1  0x77a7c99c in _ULmips_is_signal_frame () from
/usr/lib/mips-linux-gnu/libunwind.so.8
> #2  0x77a7cbb0 in _ULmips_handle_signal_frame () from
/usr/lib/mips-linux-gnu/libunwind.so.8
> #3  0x77a7d01c in _ULmips_step () from
/usr/lib/mips-linux-gnu/libunwind.so.8
> #4  0x55eaaff0 in xorg_backtrace () at ../../../../os/backtrace.c:72
> #5  0x55eb0444 in OsSigHandler (signo=11, sip=0x7fd51fc8,
unused=) at ../../../../os/osinit.c:135
> #6  

> #7  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8

#0  access_mem (as=0x77e2e260 , addr=4,
val=0x7ffe4ff8, write=0, arg=0x7fff50d0) at mips/Ginit.c:104

93  static int
94  access_mem (unw_addr_space_t as, unw_word_t addr, unw_word_t
*val, int write,
95  void *arg)
96  {
97if (write)
98  {
99Debug (16, "mem[%llx] <- %llx\n", (long long) addr, (long
long) *val);
   100*(unw_word_t *) (intptr_t) addr = *val;
   101  }
   102else
   103  {
   104*val = *(unw_word_t *) (intptr_t) addr;
   105Debug (16, "mem[%llx] -> %llx\n", (long long) addr, (long
long) *val);
   106  }
   107return 0;
   108  }

So at line 104 we're dereferencing addr, addr==4, boom.

> #8  0x77a7c99c in _ULmips_is_signal_frame () from
/usr/lib/mips-linux-gnu/libunwind.so.8

#1  0x77e1199c in _ULmips_is_signal_frame (cursor=0x7ffe50d0) at
mips/Gis_signal_frame.c:46

29  PROTECTED int
30  unw_is_signal_frame (unw_cursor_t *cursor)
31  {
32struct cursor *c = (struct cursor *) cursor;
33unw_word_t w0, w1, ip;
34unw_addr_space_t as;
35unw_accessors_t *a;
36void *arg;
37int ret;
38
39as = c->dwarf.as;
40a = unw_get_accessors (as);
41arg = c->dwarf.as_arg;
42
43ip = c->dwarf.ip;
44
45/* syscall */
46if ((ret = (*a->access_mem) (as, ip + 4, &w1, 0, arg)) < 0)
47  return 0;
48if ((w1 & 0x) != 0x0c)
49  return 0;
50

(gdb) p c->dwarf
$5 = {as_arg = 0x7fff50d0, as = 0x77e2e260 , cfa =
2147373240, ip = 0, args_size = 0, ret_addr_column = 0, eh_args = {0,
0}, eh_valid_mask = 0, loc = {{val = 2147438844}, {val = 2147438852}, {
  val = 2147438860}, {val = 2147438868}, {val = 2147438876}, {val =
2147438884}, {val = 2147438892}, {val = 2147438900}, {val = 2147438908},
{val = 2147438916}, {val = 2147438924}, {val = 2147438932}, {
  val = 2147438940}, {val = 2147438948}, {val = 2147438956}, {val =
2147438964}, {val = 2147438972}, {val = 2147438980}, {val = 2147438988},
{val = 2147438996}, {val = 2147439004}, {val = 2147439012}, {
  val = 2147439020}, {val = 2147439028}, {val = 2147439036}, {val =
2147439044}, {val = 2147439052}, {val = 2147439060}, {val = 2147439068},
{val = 2147439076}, {val = 2147439084}, {val = 2147439092}, {
  val = 0}, {val = 0}, {val = 2147438832}, {val = 0} }, stash_frames = 0, use_prev_instr = 1, pi_valid = 0,
pi_is_dynamic = 0, pi = {start_ip = 0, end_ip = 0, lsda = 0, handler = 0,
gp = 0, flags = 0, format = 0, unwind_info_size = 0, unwind_info =
0x0, extra = {}}, hint = 0, prev_rs = 0}

At line 46 we call access_mem with addr == c->dwarf.ip + 4, and
c->dwarf.ip is 0.

I'll stop there for now.

Cheers,
Julien

> #9  0x77a7cbb0 in _ULmips_handle_signal_frame () from
/usr/lib/mips-linux-gnu/libunwind.so.8

#2  0x77e11bb0 in _ULmips_handle_signal_frame (cursor=0x7ffe50d0) at
mips/Gstep.c:37

> #10 0x77a7d01c in _ULmips_step () from
/usr/lib/mips-linux-gnu/libunwind.so.8

#3  0x77e1201c in _ULmips_step (cursor=0x7ffe50d0) at mips/Gstep.c:119


> #11 0x77a7a8f8 in unw_backtrace () from /usr/lib/mips-linux-gnu/libunwind.so.8
> #12 0x55eb06b0 in OsInit () at ../../../../os/osinit.c:217
> #13 0x55e4d708 in dix_main (argc=11, argv=0x7fd639e4, envp=) 
> at ../../../../dix/main.c:154
> #14 0x7759ccf8 in __libc_start_main () from /lib/mips-linux

Bug#909242: Xvfb: segfaults on mips during gtk+3.0 build-time tests

2018-09-20 Thread Simon McVittie
Package: xvfb
Version: 2:1.20.1-2
Severity: important
X-Debbugs-Cc: debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips

My recent gtk+3.0 upload to experimental failed many of its build-time
tests on mips. The tests could not connect to the Xvfb server run by the
upstream build system, which later crashed with a segmentation fault.

https://buildd.debian.org/status/fetch.php?pkg=gtk%2B3.0&arch=mips&ver=3.24.1-1&stamp=1537406479&file=log

I can reproduce this reliably on the mips porterbox, minkus, by running
Xvfb in a schroot with the options shown below.

Core was generated by `Xvfb -ac -noreset -screen 0 1024x768x16 :1 -nolisten tcp 
-auth /dev/null'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
(gdb) bt
#0  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
#1  0x77a7c99c in _ULmips_is_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#2  0x77a7cbb0 in _ULmips_handle_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#3  0x77a7d01c in _ULmips_step () from /usr/lib/mips-linux-gnu/libunwind.so.8
#4  0x55eaaff0 in xorg_backtrace () at ../../../../os/backtrace.c:72
#5  0x55eb0444 in OsSigHandler (signo=11, sip=0x7fd51fc8, unused=) at ../../../../os/osinit.c:135
#6  
#7  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
#8  0x77a7c99c in _ULmips_is_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#9  0x77a7cbb0 in _ULmips_handle_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#10 0x77a7d01c in _ULmips_step () from /usr/lib/mips-linux-gnu/libunwind.so.8
#11 0x77a7a8f8 in unw_backtrace () from /usr/lib/mips-linux-gnu/libunwind.so.8
#12 0x55eb06b0 in OsInit () at ../../../../os/osinit.c:217
#13 0x55e4d708 in dix_main (argc=11, argv=0x7fd639e4, envp=) at 
../../../../dix/main.c:154
#14 0x7759ccf8 in __libc_start_main () from /lib/mips-linux-gnu/libc.so.6
#15 0x55d28e34 in __start ()
Backtrace stopped: frame did not save the PC

Line 217 is this backtrace() call:

#ifdef HAVE_BACKTRACE
/*
 * initialize the backtracer, since the ctor calls dlopen(), which
 * calls malloc(), which isn't signal-safe.
 */
do {
void *array;

backtrace(&array, 1); <--- here
} while (0);
#endif

so this might really be a libunwind bug (please reassign if you think so).
libunwind8:mips 1.2.1-8 was installed.

I thought this might be hardware-specific, but according to machines.cgi,
mips-sil-01 (where gtk+3.0 failed) and mips-manda-01 (where a libepoxy
build with the same xvfb and libunwind8 versions, also using Xvfb for
tests, succeeded) are matching hardware, a Rhino Labs UTM8.  minkus,
the porterbox where I reproduced this, is apparently an EdgeRouter Pro.

Xvfb is used in many packages' build-time tests, which for most
maintainers are the only evidence we have that our packages are at all
functional on mips, so it might be a good idea to work around this in
Xvfb by disabling backtrace support and/or libunwind on mips.

smcv