Setup:
- Latest Mesa from git
- Vulkan loader from VulkanTools git version (few months old)
- Ubuntu 16.04


Test-case:
- ./texture3d

Expected outcome:
- Test works fine, like few months before, and like the other Sacha Willems' demos do

Actual outcome:
- program crashes

Gdb tells following:
-----------------------------------------
Program received signal SIGBUS, Bus error.
write_reloc (flush=true, v=4290207744, p=0x8000f36510a0, device=0x894330)
    at ../../../src/intel/vulkan/anv_batch_chain.c:1124
1124	      *(uint64_t *)p = (((int64_t)v) << shift) >> shift;
(gdb) bt
#0  write_reloc (flush=true, v=4290207744, p=0x8000f36510a0, device=0x894330)
    at ../../../src/intel/vulkan/anv_batch_chain.c:1124
#1  anv_reloc_list_apply (device=0x894330, list=list@entry=0x854c78, bo=0x894f88, 
    always_relocate=always_relocate@entry=true) at ../../../src/intel/vulkan/anv_batch_chain.c:1203
#2  0x00007ffff5d78d59 in relocate_cmd_buffer (exec=0x7fffffffe510, cmd_buffer=0x854bc0)
    at ../../../src/intel/vulkan/anv_batch_chain.c:1272
#3  setup_execbuf_for_cmd_buffer (cmd_buffer=0x854bc0, execbuf=0x7fffffffe510)
    at ../../../src/intel/vulkan/anv_batch_chain.c:1383
#4  anv_cmd_buffer_execbuf (device=device@entry=0x894330, cmd_buffer=<optimized out>, 
    in_semaphores=0x713540, num_in_semaphores=1, out_semaphores=0x713548, num_out_semaphores=1, 
    _fence=0x0) at ../../../src/intel/vulkan/anv_batch_chain.c:1588
#5  0x00007ffff5d9b256 in anv_QueueSubmit (_queue=<optimized out>, submitCount=1, 
    pSubmits=<optimized out>, fence=0x0) at ../../../src/intel/vulkan/anv_queue.c:218
#6  0x0000000000452e1d in VulkanExample::draw() ()
#7  0x0000000000454d32 in VulkanExample::render() ()
#8  0x000000000046d0b1 in VulkanExampleBase::renderLoop() ()
#9  0x000000000044f07c in main ()

(gdb) info locals
shift = 16
reloc_size = 8
(gdb) print (((int64_t)v) << shift) >> shift
$1 = 4290207744
(gdb) print p
$2 = (void *) 0x8000f36510a0

(gdb) disassemble 
Dump of assembler code for function anv_reloc_list_apply:
...
   0x00007ffff5d76990 <+112>:	cmpb   $0x0,0x5f(%rdi)
=> 0x00007ffff5d76994 <+116>:	mov    %rax,0x0(%rbp)
   0x00007ffff5d76998 <+120>:	je     0x7ffff5d769c7 <anv_reloc_list_apply+167>

(gdb) info registers rax rbp
rax            0xffb76000	4290207744
rbp            0x8000f36510a0	0x8000f36510a0
-----------------------------------------

Given process doesn't even map the address it tried to write to (0x8000f36510a0):
----------------------------------------------
$ tail -4 /proc/$(pidof texture3d)/maps
7ffff7ffd000-7ffff7ffe000 rw-p 00026000 08:02 7866345                    /lib/x86_64-linux-gnu/ld-2.23.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
----------------------------------------------

Which AFAIK should give SIGSEGV instead of SIGBUS, but maybe SIGBUS issues gets caught before checks on whether given address is mapped happen.

SIGBUS comes typically from unaligned access, and here Mesa tries to do 64-bit access to 2-byte aligned address.

However, I though on Intel one gets unaligned access errors only when using specific SIMD (SSE, AVX...) instructions, HW would automatically handle unaligned accesses (with some performance cost) for normal instructions like here.

(On some platforms unaligned accesses have also other problems, like them not being atomic if they cross page boundary.)

From i915 kernel code it seems that other possibilities for SIGBUS could be accesses to a GTT mapping / aperture that run off the end of mapping, but there's no close-by mapping like that in the process maps file.


It's possible that this is related to bug 105374 (as Mesa I'm testing is built without "--enable-debug" option).