(single threaded?) data race during acceleration structure construction

[TirushOne]

I am trying to get some ray tracing going, but I hit a really perplexing bug in the process. The console was telling me I was submitting a "OneTimeSubmit" command buffer twice, which I definatley am not. My program is single threaded and all my command buffers are distoryed within 10 lines of their creation and aren't passed around anywhere. So I tried changing the buffer at line 204 (the one responsible for exacting acceleration structure building) to be "SimaltaniousUse" to see if that would fix the problem, it didn't. Instead it started telling me
access to a resource has been denied (resource use: Some(ResourceUseRef { command_index: 0, command_name: "build_acceleration_structure", resource_in_command: Destination, secondary_use_ref: None }), error: the resource is already in use, and there is no tracking of concurrent usages)
This is offending section of code
`let mut command_buf = AutoCommandBufferBuilder::primary(
context.command_buffer_alloc.clone(),
context.queue.queue_family_index(),
CommandBufferUsage::OneTimeSubmit,
).unwrap();

    unsafe {
        command_buf.build_acceleration_structure(
            build_input,
            smallvec![
                AccelerationStructureBuildRangeInfo {
                    primitive_count: self.index_data.len() as u32,
                    primitive_offset: 0,
                    first_vertex: 0,
                    transform_offset: 0,
                }
            ]
        )?;
    }

    command_buf.
        build()
        .unwrap()
        .execute(context.queue.clone())
        .unwrap()
        .then_signal_fence_and_flush()
        .unwrap()
        .wait(None)
        .unwrap();` 

You might notice there is nothing concurrent or otherwise tricey going on here, it seems so straight forward, but apparently it's anything but. There seems to be a data race component to this. On my machine if I set the 'tris' varible to <~ 115, main.rs will run without issue, but once you get above that, there is a huge hitch on my whole pc and a spike in cpu usage that seems completely disconnected from the number of triangles being processed, and then the panic message is returned. On release it breaks at exactly the same number of triangles however, so perhaps it's not a data race.

I notice this has been labelled as not going to be fixed, is there a less buggy sync api I could use instead?

The full source code is available as a zip archive attached.
ray_tracing.zip