On entry to ZGEBAL parameter number 3 had an illegal value

[bo b change]

Hello,

I encountered a problem when I run a Lua program using Cygwin on Windows. The error notes: On entry to ZGEBAL parameter number  3 had an illegal value. Because ZGEBAL belongs to Lapack, I hope people familiar with Openblas can solve it.

Here are some conclusions I found:

1) For the same code, maybe the first time I run it, there is nothing wrong. And at the second time I run it, the error occurs. 

2) For my code, I am doing a kind of parameter sweeping in Lua by using another packaged program called S4. In a loop, some parameters return this error, and the program stops.

Since we cannot avoid the NaN value in some parameters, whether we can skip these points and make the program go ahead.

Best regards

Thanks

[Marco Atzeri]

Hi Bo,
is it happening also without openblas, so with only the
reference netlib blas ?

you can test with just

mv /usr/bin/cygblas-0.dll /usr/bin/cygblas-0.dll-bk

and the reference blas in

/usr/lib/lapack/cygblas-0.dll

will take over.

If is happening also with reference blas than is not a Openblas issue
but a purely Lapack.
Can you provide a simple test case ?

Regards
Marco Atzeri
Openblas and Lapack cygwin package maintainer

[Marco Atzeri]

On 29.12.2021 05:12, bo b change wrote:
> Hi Marco,
> Thanks for your advice.
> Following your advice, I retest my code, and it returns:
> "D:/Software/Cygwin/Cygwin64/home/Thinkpad/S4-master/build/s4.exe: error
> while loading shared libraries: cygblas-0.dll: cannot open shared object
> file: No such file or directory"

probably you need the command "hash -r" to forget the previous location
/usr/bin/cygblas-0.dll

> So, I "make clean" my code and make makefile again. Then I test the code
> again. Unfortunately, the same error occurred: "On entry to ZGEBAL

> parameter number  3 had an illegal value".
>

> Besides, I checked the Developer Info of S4, it writes the following
> about LAPACK:
>  "If a precompiled LAPACK library is used, ensure ZGEEV is thread safe
> for large matrices. Specifically, bug0061
> <http://netlib.org/lapack/Errata/index2.html#_strong_span_class_red_bug0061_span_strong_zgehrd_f_is_overflowing> in
> the LAPACK errata means that the maximum stack space reserved by the
> Fortran compiler used to build LAPACK must be sufficient to hold certain
> temporaries on the stack instead of in static (shared) memory. The best
> way to avoid this with GFortran is to use the -frecursive flag. A simple
> test of thread safety is provided in
> the testing/Lapackthreadtest/ directory. If no LAPACK library is
> available, the default RNP routines are used, which are suboptimal due
> to lack of blocked routines. However, they are definitely thread-safe."
>
> So, whether there is something wrong related with thread or stack space?
> Could you give me some suggestions?

thanks for the reference and the suggestion on the S4 site.
The Lapackthreadtest currently fails

I am trying to rebuild lapack with the "-frecursive" flag,
if that make difference I will upload a new test package for Lapack
so that you can test it

> Best regards,
> Bob

[bo b change]

Thank you very much! FYI, https://web.stanford.edu/group/fan/S4/dev_info.html

Best regards

Bob