Operations on shader program freezes GL context when using big enough SSBO - opengl

Question

I am doing parallel reduction in a compute shader. I am recursively computing the bounding box of chunks of fragments (starting from a G-buffer resulting from a scene render), and then the bounding box of chunks of bounding boxes, and so on until I end up with a single bounding box.
Initially I was doing this with a depth texture and a single vec2 holding the min and max depths, and I was storing the hierarchy in an SSBO like so :
// Each tile holds the min and max depth of the subtiles in the level under it.
// Each tile holds 32 items and is 8*4 or 4*8 depending on the level. Conceptually,
// the texDepth texture is level 4.
layout(std430, binding = 5) buffer aabbHierarchy
{
vec2 level0[8 * 4], // one 8*4 tile
level1[32 * 32], // 8*4 4*8 tiles
level2[256 * 128], // 32*32 8*4 tiles
level3[1024 * 1024]; // 256*128 4*8 tiles
};
Eventually I ran into issues and decided to switch to full AABBs. The structure and SSBO changed like so :
struct AABB
{
vec4 low, high;
};
layout(std430, binding = 5) buffer aabbHierarchy
{
AABB level0[8 * 4],
level1[32 * 32],
level2[256 * 128],
level3[1024 * 1024];
};
Of course I changed everything related to performing the actual calculation accordingly.
But now, as it turns out, the GL context freezes when I issue any call after a glUseProgram on this program. The glUseProgram call in itself has no problems whatsoever, but any GL call I do after it hangs my application. This obviously did not happen when initially using vec2.
I have done the math, and my SSBO is 34,636,800 bytes (with AABB), which is far smaller than the SSBO block size limit of 128 MB. At no point in my application is glCheckError returning anything other than 0, and all my shader compilations, buffer allocations and texture creations all work (at least they don't return an error). As an added bonus, allocating the same size of SSBO as with AABB but using it as vec2 in the shader does not make the application freeze.
I am using an OpenGL 4.4 context with #version 430 in the compute shader, with no extension. This is running on an ASUS RoG fx553vd with an Nvidia GeForce GTX 1050 in it.
EDIT : since I couldn't replicate in an MCVE, it must be something to do with the code around it. Still, the complete lack of error reporting is really weird. I was able to find the very line that provoked the error, and to reproduce the fact that in this context, any GL call (even as simple as glGetIntegerv) would freeze the application.
It's a pretty big project, so sorry for that. The problematic line is there, while the project's root is there. Please note that this is the aabbHierarchy branch, not master. I added extensive tracing just to make it clear where and when the program crashes.
EDIT 2 : I added an OpenGL debug context, and all it did for me was print out a couple lines of "buffer detailed info" that don't help.

Answer 1

Turns out it's a driver issue. I was able to provide a minimal working example which freezes on my Nvidia but works perfectly on my Intel integrated GPU.
For future reference, as of 02/06/2019 the Nvidia driver is taking ages to use compute shaders which declare arrays of structures in buffer interface blocks. This works fine :
layout(std430, binding = 0) buffer bleh
{
vec2 array[100000];
};
but this will take 5 actual seconds to finish executing glUseProgram :
struct AABB
{
vec2 a;
};
layout(std430, binding = 0) buffer bleh
{
AABB array[100000];
};
Mine looks like a freeze because I'm allocating over 30 MB of buffer-backed shader storage through a structure, which is a perfectly okay thing to do, but seeing how the Nvidia driver takes 5 seconds to deal with 100 KB, I can only wonder how much time that's going to take.
On my Intel GPU, the glUseProgram call for both executes instantly. I will report this to Nvidia ASAP.