Bug 106147 - SIGBUS in write_reloc() when Sacha Willems' "texture3d" Vulkan demo starts
Summary: SIGBUS in write_reloc() when Sacha Willems' "texture3d" Vulkan demo starts
Status: VERIFIED DUPLICATE of bug 105374
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2018-04-20 12:41 UTC by Eero Tamminen
Modified: 2018-04-23 12:14 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Eero Tamminen 2018-04-20 12:41:44 UTC
- Latest Mesa from git
- Vulkan loader from VulkanTools git version (few months old)
- Ubuntu 16.04

- ./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).
Comment 1 Jason Ekstrand 2018-04-21 05:03:12 UTC

*** This bug has been marked as a duplicate of bug 105374 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.