Debian Bug report logs - #919197
qtwayland-opensource-src: FTBFS on hppa - Segmentation faults in testsuite

Full log

Message #20 received at [email protected] (full text, mbox, reply):

Received: (at 919197) by bugs.debian.org; 13 Jan 2019 22:55:25 +0000
From [email protected] Sun Jan 13 22:55:25 2019
X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
	(2018-09-13) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-10.4 required=4.0 tests=BAYES_00,DIGITS_LETTERS,
	FOURLA,HAS_BUG_NUMBER,MONEY,RCVD_IN_DNSWL_LOW,SPF_PASS,STOCKLIKE,TXREP,
	UNPARSEABLE_RELAY autolearn=ham autolearn_force=no
	version=3.4.2-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 12; hammy, 150; neutral, 91; spammy,
	0. spammytokens: hammytokens:0.000-+--HOpenpgp:signencrypt,
	0.000-+--HOpenpgp:preference, 0.000-+--H*u:60.0, 0.000-+--gcc7,
	0.000-+--gcc-7
Return-path: <[email protected]>
Received: from simcoe207srvr.owm.bell.net ([184.150.200.207] helo=torfep01.bell.net)
	by buxtehude.debian.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <[email protected]>)
	id 1giof7-0008HW-CT
	for [email protected]; Sun, 13 Jan 2019 22:55:25 +0000
Received: from bell.net torfep01 184.150.200.158 by torfep01.bell.net
          with ESMTP
          id <[email protected]>
          for <[email protected]>; Sun, 13 Jan 2019 17:55:22 -0500
Received: from [192.168.2.49] (really [70.53.62.20]) by torspm01.bell.net
          with ESMTP
          id <20190113225522.XNAC10318.torspm01.bell.net@[192.168.2.49]>;
          Sun, 13 Jan 2019 17:55:22 -0500
Subject: Re: Bug#919197: Acknowledgement (qtwayland-opensource-src: FTBFS on
 hppa - Segmentation faults in testsuite)
From: John David Anglin <[email protected]>
To: [email protected]
References: <154740546422.30868.16553015018522994602.reportbug@mx3210>
 <[email protected]>
 <[email protected]>
Openpgp: preference=signencrypt
Message-ID: <[email protected]>
Date: Sun, 13 Jan 2019 17:55:22 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Cloudmark-Analysis: v=2.2 cv=N5jGLy1B c=1 sm=0 tr=0 a=O1s9vCNsZHvkjbFmGvGkaA==:17 a=IkcTkHD0fZMA:10 a=3JhidrIBZZsA:10 a=FBHGMhGWAAAA:8 a=IuZio7OyuGq7Cw7KpYkA:9 a=QEXdDO2ut3YA:10 a=9gvnlMMaQFpL9xblJ6ne:22

On 2019-01-13 2:52 p.m., John David Anglin wrote:
> Looks to me to be a NULL pointer check issue in mesa:
>
> static inline struct wl_drm_buffer *
> wayland_drm_buffer_get(struct wl_drm *drm, struct wl_resource *resource)
> {
>         if (resource == NULL)
>                 return NULL;
>
>         if (wl_resource_instance_of(resource, &wl_buffer_interface,
>                                     &drm->buffer_interface))
>                 return wl_resource_get_user_data(resource);
>         else
>                 return NULL;
> }
>
> (gdb) disass $pc-32-16,$pc+16
> Dump of assembler code from 0xec46dd14 to 0xec46dd54:
>    0xec46dd14 <dri2_query_wayland_buffer_wl+0>: stw rp,-14(sp)
>    0xec46dd18 <dri2_query_wayland_buffer_wl+4>: ldo 80(sp),sp
>    0xec46dd1c <dri2_query_wayland_buffer_wl+8>: ldw -b4(sp),ret0
>    0xec46dd20 <dri2_query_wayland_buffer_wl+12>:        stw r5,-74(sp)
>    0xec46dd24 <dri2_query_wayland_buffer_wl+16>:        copy r23,r5
>    0xec46dd28 <dri2_query_wayland_buffer_wl+20>:        stw r4,-70(sp)
>    0xec46dd2c <dri2_query_wayland_buffer_wl+24>:        stw r3,-6c(sp)
>    0xec46dd30 <dri2_query_wayland_buffer_wl+28>:        stw r19,-20(sp)
>    0xec46dd34 <dri2_query_wayland_buffer_wl+32>:        stw ret0,-78(sp)
>    0xec46dd38 <dri2_query_wayland_buffer_wl+36>:        ldw 58(r25),ret0
>    0xec46dd3c <dri2_query_wayland_buffer_wl+40>:        ldo c0(ret0),ret0
>    0xec46dd40 <dri2_query_wayland_buffer_wl+44>:        movb,=
> r24,r3,0xec46dd94 <dri2_query_wayland_buffer_wl+128>
> => 0xec46dd44 <dri2_query_wayland_buffer_wl+48>:        ldw 0(ret0),ret0
>    0xec46dd48 <dri2_query_wayland_buffer_wl+52>:        addil L%800,r19,r1 
>    0xec46dd4c <dri2_query_wayland_buffer_wl+56>:        copy r19,r4
>    0xec46dd50 <dri2_query_wayland_buffer_wl+60>:        ldw 200(r1),r25
>
> The NULL pointer check has bee4n optimized away.
Actually, it has only been partially optimized away.  It appears the
check is still there (movb instruction)
but register r3 contains an undefined value (it is not an argument
register).  So, this seems a wrong
code bug.

Why are we building with gcc-7?

-- 
John David Anglin  [email protected]

Send a report that this bug log contains spam.