Comment 2 for bug 1271649

(There are multiple runs in the data below. /dev/fb0 is not mmaped to the same address for the process so you'll see variability that is there. The important thing to keep in mind is that the mmapped address range is valid and that the memcpys into that range have a destination that is in that mapped range)

I've created a simple little program to open up /dev/fb0 and write out a test pattern to the whole 1024x768 at 16bpp. This works.

I've instrumented X and loaded on a debug build.

The failure via gdb looks like :

#0 memcpy () at ../ports/sysdeps/aarch64/memcpy.S:75
#1 0x0000007f7f9c2018 in shadowUpdatePacked (pScreen=0x3f4269b0,
    pBuf=0x3f428020) at shpacked.c:103
#2 0x0000007f7f9c18d4 in shadowRedisplay (pScreen=0x3f4269b0) at shadow.c:62
#3 0x000000000043a964 in BlockHandler (pTimeout=pTimeout@entry=0x7fdcbf8020,
    pReadmask=0x5ab9f8 <LastSelectMask>) at dixutils.c:394
#4 0x000000000055760c in WaitForSomething (
    pClientsReady=pClientsReady@entry=0x3f579c80) at WaitFor.c:210
#5 0x0000000000436724 in Dispatch () at dispatch.c:361
#6 0x00000000004266dc in main (argc=2, argv=0x7fdcbf82b8,
    envp=<optimized out>) at main.c:298
(gdb) frame 1
#1 0x0000007f7f9c2018 in shadowUpdatePacked (pScreen=0x3f4269b0,
    pBuf=0x3f428020) at shpacked.c:103
103 memcpy(win, sha, i * sizeof(FbBits));
(gdb)
#1 0x0000007f7f9c2018 in shadowUpdatePacked (pScreen=0x3f4269b0,
    pBuf=0x3f428020) at shpacked.c:103
103 memcpy(win, sha, i * sizeof(FbBits));
(gdb) p win
$1 = (FbBits *) 0x7f7f8ffbfc
(gdb) p sha
$2 = (FbBits *) 0x7f7ecfec0c
(gdb) p size
No symbol "size" in current context.
(gdb) p i
$3 = <optimized out>

It's important to note that the kernel spits out this when the error occurs :

[ 1410.063428] Unhandled fault: alignment fault (0x92000061) at 0x0000007f9ccd1bfc

The first 32 bit value I'm pretty sure is the ESR. So
EC == 0b100100 aka data alignment or access fault
IL = 1 or 32 bit instruction
ISS breaks down to
   1 COND isn't valid
   buncha reserved bits
   1 = WFI / WFE trapped

Now about that memcpy : this code in X, specifically shadowUpdatePacked is called a fair amount. It's done a bunch of writing into the mmaped range for /dev/fb0 already.

The failing memcpy is using the following :

memcpy 7f9ccd1bfc win 7f9c0d0c0c sha 00000018 size 6 i 4 FbBits

yet moments ago there was a good long loop... here's a snipped from the output:

win & sha (source and destination address)
size is the amount copied in hex bytes.
i and FbBits I am dumping out because the size was a calculation of those two. (I was curious what FbBits was set to) Anyway the size and addresses are all multiples of 4.

memcpy 7f9cd8e800 win 7f9c18d810 sha 00000800 size 200 i 4 FbBits
memcpy 7f9cd8f000 win 7f9c18e010 sha 00000800 size 200 i 4 FbBits
memcpy 7f9cd8f800 win 7f9c18e810 sha 00000800 size 200 i 4 FbBits
memcpy 7f9cd90000 win 7f9c18f010 sha 00000800 size 200 i 4 FbBits
memcpy 7f9cd90800 win 7f9c18f810 sha 00000800 size 200 i 4 FbBits
memcpy 7f9cd91000 win 7f9c190010 sha 00000800 size 200 i 4 FbBits
memcpy 7f9cd91800 win 7f9c190810 sha 00000800 size 200 i 4 FbBits