Nondeterministic SSBO has GL_BUFFER_DATA_SIZE too small after glBufferData

Question

I seem to have nondeterministic data in my Shader Storage Buffer.

I used apitrace to inspect the state machine and noticed the following sequence of function calls in the trace:

glBindBuffer (GL_SHADER_STORAGE_BUFFER, 3);
glBufferData (GL_SHADER_STORAGE_BUFFER, 36, NULL, GL_DYNAMIC_DRAW);
glBufferSubData (GL_SHADER_STORAGE_BUFFER, 0, 4, [binary data, size = 4 bytes])
glBufferSubData (GL_SHADER_STORAGE_BUFFER, 4, 32, [binary data, size = 32 bytes])

This appears to be correct according to the higher-level application code, it matches setting this

layout (std140) buffer Components
{
    int count;
    vec4 colour [];
}
b_components;

to a length-prefixed array glm::vec4[2].

However, apitrace shows that GL_BUFFER_DATA_SIZE is 32, not 36, at every stage in the above trace.

Also, here's an inspection of the SSBO:

Components.colour[0] has GL_ARRAY_SIZE=0 (shouldn't this be nonzero?) and GL_OFFSET=16 (shouldn't this be 4?)

The program is very simple, so for good measure, here's the full trace (this is for Frame 1, the glBufferData(...,36,...) was in Frame 0 and has not been repeated):

1. Shouldn't the SSBO have GL_BUFFER_DATA_SIZE=36, given my call to glBufferData? If so, is this a driver bug? If its stated size of 32 is correct, can you please explain how that makes sense?

2. Are the GL_ARRAY_SIZE and GL_OFFSET correct?

3. Given that inspecting the glBufferSubData calls, my array glm::vec4[2] describes correct, deterministic data, is there anything in this trace which would explain why, when I read b_components.colour[i] within for (int i = 0; i < b_components.count; ++i) that I get nondeterministic results?