NetBSD Problem Report #58120
From www@netbsd.org Sat Apr 6 14:23:22 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id C32911A923B
for <gnats-bugs@gnats.NetBSD.org>; Sat, 6 Apr 2024 14:23:22 +0000 (UTC)
Message-Id: <20240406142321.401921A923C@mollari.NetBSD.org>
Date: Sat, 6 Apr 2024 14:23:21 +0000 (UTC)
From: brandon@burn.net
Reply-To: brandon@burn.net
To: gnats-bugs@NetBSD.org
Subject: xeyes dies with bus error/core dump on 10.0 sparc
X-Send-Pr-Version: www-1.0
>Number: 58120
>Category: port-sparc
>Synopsis: xeyes dies with bus error/core dump on 10.0 sparc
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: port-sparc-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Apr 06 14:25:00 +0000 2024
>Last-Modified: Wed Apr 24 16:15:01 +0000 2024
>Originator: Brandon Applegate
>Release: 10.0
>Organization:
>Environment:
>Description:
On a fresh install of 10.0 - xeyes will launch and display - however at the first movement of the mouse pointer it crashes (bus error). I do have a core dump, I need to figure out how to attach it to the PR or get it uploaded somewhere.
I have tried this on both an SS10 and an IPX (so 4m and 4c respectively) and get the same result.
>How-To-Repeat:
Run xeyes on a 10.0 sparc system.
>Fix:
>Audit-Trail:
From: Brandon Applegate <brandon@burn.net>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-sparc/58120: xeyes dies with bus error/core dump on 10.0
sparc
Date: Sat, 6 Apr 2024 10:26:59 -0400 (EDT)
I have put the core file up for download:
https://burn.net/xeyes.core
From: Brandon Applegate <brandon@burn.net>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-sparc/58120: xeyes dies with bus error/core dump on 10.0
sparc
Date: Thu, 11 Apr 2024 19:17:53 -0400 (EDT)
I also have a ktrace output:
https://burn.net/xeyes-ktrace.out
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-sparc/58120: xeyes dies with bus error/core dump on 10.0
Date: Fri, 12 Apr 2024 16:45:09 +0200
This is also reproducable on -current:
(gdb) bt
#0 0xe5eaaa84 in wireToRawEvent (cookie=<optimized out>, in=0xe58d62d0,
info=<optimized out>)
at /work/xsrc/external/mit/libXi/dist/src/XExtInt.c:1993
#1 XInputWireToCookie (dpy=<optimized out>, cookie=<optimized out>,
event=0xe58d62d0) at /work/xsrc/external/mit/libXi/dist/src/XExtInt.c:1008
#2 0xe5cc5858 in _XEnq (dpy=0xe5af6000, event=0xe58d62d0)
at /work/xsrc/external/mit/libX11/dist/src/XlibInt.c:771
#3 0xe5c9adb4 in handle_response (dpy=<optimized out>, response=0xe58d62d0,
in_XReply=0) at /work/xsrc/external/mit/libX11/dist/src/xcb_io.c:417
#4 0xe5c9b5dc in _XEventsQueued (mode=1, dpy=0xe5af6000)
at /work/xsrc/external/mit/libX11/dist/src/xcb_io.c:442
#5 _XEventsQueued (dpy=0xe5af6000, mode=1)
at /work/xsrc/external/mit/libX11/dist/src/xcb_io.c:423
#6 0xe5c58ba4 in XEventsQueued (dpy=0xe5af6000, mode=1)
at /work/xsrc/external/mit/libX11/dist/src/Pending.c:43
#7 0xe5e2f704 in FindInputs (nfds=<optimized out>,
found_input=<optimized out>, dpy_no=<optimized out>,
ignoreInputs=<optimized out>, ignoreEvents=<optimized out>,
wf=<optimized out>, app=<optimized out>)
at /work/xsrc/external/mit/libXt/dist/src/NextEvent.c:404
#8 _XtWaitForSomething (app=0xe5b5a000, ignoreEvents=<optimized out>,
ignoreTimers=<optimized out>, ignoreInputs=<optimized out>,
ignoreSignals=<optimized out>, block=<optimized out>, drop_lock=0 '\000',
howlong=<optimized out>)
at /work/xsrc/external/mit/libXt/dist/src/NextEvent.c:754
#9 0xe5e30f40 in XtAppProcessEvent (app=0xe5b5a000, mask=15)
at /work/xsrc/external/mit/libXt/dist/src/NextEvent.c:1419
#10 0xe5e3ed90 in XtAppMainLoop (app=0xe5b5a000)
at /work/xsrc/external/mit/libXt/dist/src/Event.c:1618
#11 0x000139e0 in main (argc=<optimized out>, argv=<optimized out>)
at /work/xsrc/external/mit/xeyes/dist/xeyes.c:145
(gdb) x/16i $pc-32
0xe5eaaa64 <XInputWireToCookie+584>: ldd [ %g1 ], %f14
0xe5eaaa68 <XInputWireToCookie+588>: fmovs %f14, %f12
0xe5eaaa6c <XInputWireToCookie+592>: b 0xe5eaaa78 <XInputWireToCookie+604>
0xe5eaaa70 <XInputWireToCookie+596>: fmovs %f15, %f13
0xe5eaaa74 <XInputWireToCookie+600>: ld [ %i0 + 0x34 ], %i3
0xe5eaaa78 <XInputWireToCookie+604>: sll %g2, 3, %g1
0xe5eaaa7c <XInputWireToCookie+608>: ld [ %i2 ], %f8
0xe5eaaa80 <XInputWireToCookie+612>: fitod %f8, %f8
=> 0xe5eaaa84 <XInputWireToCookie+616>: std %f8, [ %i3 + %g1 ]
0xe5eaaa88 <XInputWireToCookie+620>: ld [ %i2 + 4 ], %i3
0xe5eaaa8c <XInputWireToCookie+624>: ld [ %i2 + 4 ], %f8
0xe5eaaa90 <XInputWireToCookie+628>: cmp %i3, 0
0xe5eaaa94 <XInputWireToCookie+632>: fitod %f8, %f8
0xe5eaaa98 <XInputWireToCookie+636>:
bge 0xe5eaaab4 <XInputWireToCookie+664>
0xe5eaaa9c <XInputWireToCookie+640>: ld [ %i0 + 0x34 ], %g3
0xe5eaaaa0 <XInputWireToCookie+644>: sethi %hi(0), %i3
(gdb) info registers
g0 0x0 0
g1 0x0 0
g2 0x0 0
g3 0x0 0
g4 0x10 16
g5 0xe5b399e0 -441214496
g6 0x0 0
g7 0xe5b76b58 -440964264
o0 0xe57fa88c -444618612
o1 0xe58d62f8 -443718920
o2 0x8 8
o3 0xe5b76130 -440966864
o4 0x8 8
o5 0x0 0
sp 0xe7fff0e8 0xe7fff0e8
o7 0xe5eaaa28 -437605848
l0 0x51 81
l1 0xe58d62f0 -443718928
l2 0x2 2
l3 0xe838a400 -398941184
l4 0xf096a9c0 -258561600
l5 0x0 0
l6 0x0 0
l7 0xe5ebd45c -437529508
i0 0xe57fa850 -444618672
i1 0x1c5ffd6 29753302
i2 0xe58d62f8 -443718920
i3 0xe57fa894 -444618604
i4 0x14 20
i5 0x2 2
fp 0xe7fff168 0xe7fff168
i7 0xe5cc5850 -439592880
y 0x0 0
psr 0x4001085 [ S EF ]
wim <unavailable>
tbr <unavailable>
pc 0xe5eaaa84 0xe5eaaa84 <XInputWireToCookie+616>
npc 0xe5eaaa88 0xe5eaaa88 <XInputWireToCookie+620>
fsr 0x80020 [ NXC ]
csr <unavailable>
values = (FP3232*)(((char*)&in[1]) + in->valuators_len * 4);
for (i = 0; i < bits; i++)
{
out->valuators.values[i] = values->integral;
out->valuators.values[i] += ((double)values->frac / (1 << 16) / (1 << 16));
(gdb) p &out->valuators.values[i]
$11 = (double *) 0xe57fa894
So output is not properly aligned for a double value.
A few lines before:
out->valuators.values = next_block(&ptr, bits * sizeof(double));
and
(gdb) p bits
$13 = 2
and next_block() does not care about alignment, but just moves the ptr
forward by the size given.
So first next_block() advances by sizeof(XIRawEvent)
(gdb) p sizeof(XIRawEvent)
$14 = 60
next one by out->valuators.mask_len
(gdb) p out->valuators.mask_len
$15 = 8
and that is the only-4-byte aligned offset we try to write the double to.
Martin
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-sparc/58120: xeyes dies with bus error/core dump on 10.0
Date: Sat, 13 Apr 2024 13:42:29 +0200
I was curious why it doesn't crash on 32bit powerpc and found the
misalignment happens there too:
(gdb) p &out->valuators.values[i]
$7 = (double *) 0xfd6c4894
(gdb) p i
$8 = 0
but the code does not trap
(gdb) x/16i $pc-32
0xfdead988 <XInputWireToCookie+692>: xoris r8,r8,32768
0xfdead98c <XInputWireToCookie+696>: stw r8,92(r1)
0xfdead990 <XInputWireToCookie+700>: lfd f0,88(r1)
0xfdead994 <XInputWireToCookie+704>: fsub f0,f0,f10
0xfdead998 <XInputWireToCookie+708>: stfdx f0,r27,r9
0xfdead99c <XInputWireToCookie+712>: stw r10,96(r1)
0xfdead9a0 <XInputWireToCookie+716>: lwz r6,4(r31)
0xfdead9a4 <XInputWireToCookie+720>: lwz r8,52(r25)
=> 0xfdead9a8 <XInputWireToCookie+724>: stw r6,100(r1)
0xfdead9ac <XInputWireToCookie+728>: lfd f0,96(r1)
0xfdead9b0 <XInputWireToCookie+732>: lfdx f9,r8,r9
0xfdead9b4 <XInputWireToCookie+736>: fsub f0,f0,f11
0xfdead9b8 <XInputWireToCookie+740>: fmul f0,f0,f12
0xfdead9bc <XInputWireToCookie+744>: fmadd f0,f0,f12,f9
0xfdead9c0 <XInputWireToCookie+748>: stfdx f0,r8,r9
0xfdead9c4 <XInputWireToCookie+752>: stw r10,104(r1)
(gdb) info reg
r0 0xfdead8f0 4260026608
r1 0xffffe150 4294959440
r2 0xfde72008 4259782664
r3 0xfd6c488c 4251732108
r4 0x14 20
r5 0x0 0
r6 0x0 0
r7 0x1 1
r8 0xfd6c4894 4251732116
r9 0x0 0
r10 0x43300000 1127219200
r11 0xfd9f0c50 4255059024
r12 0xfda16fc0 4255215552
r13 0x181e65c 25290332
r14 0x0 0
r15 0xffffe4c0 4294960320
r16 0x28424442 675431490
r17 0xffffe4d4 4294960340
r18 0xffffe4d9 4294960345
r19 0xffffe4d8 4294960344
r20 0xffffe358 4294959960
r21 0x0 0
r22 0x10 16
r23 0xfd7802f0 4252500720
r24 0x51 81
r25 0xfd6c4850 4251732048
r26 0xfd794000 4252581888
r27 0xfd6c4894 4251732116
r28 0x28 40
r29 0x2 2
r30 0xfdecb16c 4260147564
r31 0xfd7802f8 4252500728
pc 0xfdead9a8 0xfdead9a8 <XInputWireToCookie+724>
msr <unavailable>
cr 0x44224248 1143095880
lr 0xfdead92c 0xfdead92c <XInputWireToCookie+600>
ctr 0x2 2
xer 0x0 0
fpscr 0xfff80000 -524288
vscr <unavailable>
vrsave <unavailable>
On sparc64 the misalignment does not happen because XIRawEvent has a
proper multiple of 8 size:
(gdb) p &out->valuators.values[i]
$2 = (double *) 0x404b84c8
(gdb) p sizeof(XIRawEvent)
$3 = 96
Martin
From: Brandon Applegate <brandon@burn.net>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-sparc/58120: xeyes dies with bus error/core dump on 10.0
Date: Wed, 24 Apr 2024 12:08:38 -0400 (EDT)
Hey Martin,
Thanks for digging into this. Will the fix be incuded in 10.0.1/10.1
(whatever comes next) ?
In the mean time, once the fix is commited, would I be able to "cheat" and
extract the binary from something like the xbase.tgz (I assume that's
where it lives...) from a -daily build or something ?
--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A
"For thousands of years men dreamed of pacts with demons.
Only now are such things possible."
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: port-sparc-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, brandon@burn.net
Subject: Re: port-sparc/58120: xeyes dies with bus error/core dump on 10.0
Date: Wed, 24 Apr 2024 18:14:49 +0200
On Wed, Apr 24, 2024 at 04:10:01PM +0000, Brandon Applegate wrote:
> Thanks for digging into this. Will the fix be incuded in 10.0.1/10.1
> (whatever comes next) ?
Certainly.
> In the mean time, once the fix is commited, would I be able to "cheat" and
> extract the binary from something like the xbase.tgz (I assume that's
> where it lives...) from a -daily build or something ?
Let's find out where the real cause is and how to fix it first, then
we can talk about the details...
Martin
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2024
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home