I don't really understand your question. CPU caches are of course orders of magnitude smaller. However I fail to understand your logic here, since the multiplication between two different matrices does not segfault. And in that case the input size is twice as much with output size being the same.

Or am I missing something?

The last one is puzzling. We do have an optimization to detect a @ a.T (same memory pointer, switched shapes) and use the *SYRK routines instead of the *GEMM routines, but I see from your stack trace your are hitting the *GEMM routine anyway. That does not explain why it segfaults, but I do wonder why it does not go via the *SYRK routines.

If you look at #4 in the stack trace, there is:

#4  0x00007fc6f00b08ab in cblas_dsyrk ()

So i think it goes to the *SYRKroutine.

If you have any suggestions/tips how to debug that further I can certainly give it a try.

Thanks. It seems the segfaults are only in the SYRK codepath, which the last variant avoids since it copies the data. I am not familiar with the OpenBLAS internals. Maybe @martin-frbg has a thought? Did you try using fewer threads with OPENBLAS_NUM_THREADS=1 (which may be significantly slower)?

Oh yeah, I did and clearly forgot to mention that. Yes, OPENBLAS_NUM_THREADS=1 fixes the issue.

@mattip Bet it is BUFFERSIZE too small for the multithreaded GEMM routines - remember you build with a custom value to reduce the memory footprint of "everyday small matrix cases" (#18141) but that is bound to go wrong for "large" matrices.

Ahh thanks, makes sense. Is there a way we can trap this without segfaulting and warn the user to use fewer threads?

Hi, my comment is simply to highlight that this issue still present. Moreover, the temporary solutions also still work.

It is not a critical issue, but I simply wanted to leave a comment if ever someone wanted to work on it in the near future.

I guess it would be possible to calculate columns times rows times bytes per variable type and check if that fits into the compile-time BUFFERSIZE for the bundled OpenBLAS (which IIRC is built with a smaller-than-default buffer allocation to reduce memory footprint). OTOH it would probably be tedious to do this every time, and one couldn't be sure the user is
actually using the pip/conda-bundled library. On the OpenBLAS side, I'm not sure either if it would be easy to detect an impending overflow, let alone do anything about it, without losing performance in "normal" operation.