version 0.3.29 corrupts JNI system call?

[Mathadon]

I'm using OpenBLAS as a dependency in a larger software framework. After updating our dockerized installation to OpenBLAS 0.3.29 a weird error suddenly occurred where a call from a java JNI application (java called from C++) to the ProcessBuilder class to execute a command (i.e. gcc --version in this case) results in a StackOverflowException:

Exception: java.lang.StackOverflowError thrown from the UncaughtExceptionHandler in thread "process reaper"

It turns out that we do not get this bug when using OpenBLAS 0.3.28, leading to the perhaps somewhat premature conclusion that OpenBLAS is causing this. What might be relevant is that the installation also contains an alternative BLAS installation.

Feel free to let me know if we can help to narrow it down by trying a few specific commits in between v0.3.28 and v0.3.29.

[martin-frbg]

I'm not aware of any changes in 0.3.29 that could cause this - possibly you've been living dangerously close to your default stack size limit all the time and just need to increase the java stack, whether OpenBLAS is in the picture or not. (I assume your innocent call to gcc --version needs to instatiate a shell environment)

[Mathadon]

@martin-frbg thanks for the quick feedback. The java stack size is already at 16 MB and is running on a much smaller/simpler problem than usually, where no stack size problems are encountered.

The call to gcc just fetches the gcc version before building a new compile command afterwards using that version number as an argument.

[martin-frbg]

Does it (appear to) work with an even larger stack, or does limiting the number of threads via OPENBLAS_NUM_THREADS help ? And are there any differences in the way you built OpenBLAS between the two versions ? As stated I do not think there is any fundamental difference in memory requirements between them, but if you were inadvertently pitching a single-threaded build against a multithreaded one, or running the same code on more cores than before...