On Sun, 25 Oct 2020, Sven Schreiber wrote:
Am 25.10.2020 um 16:04 schrieb Allin Cottrell:
> On Sun, 25 Oct 2020, Allin Cottrell wrote:
>
>> So an interesting test on macOS would be to set GRETL_OLD_EV=1 and see
>> if the problem persists.
>
> I just tried on macOS 10.15.6: I got the crash that Fred reported, but
> when I set GRETL_OLD_EV=1 there was no crash.
>
> It turns out this is an Apple bug: there are two arguments to DSYEVR
> that are not supposed to be referenced when the function is called in
> the mode gretl uses (according to the netlib LAPACK docs). So we were
> just passing NULL for those arguments. But apparently Apple's DSYEVR
> does reference them, hence a crash on dereferencing a null pointer. In
> git (snapshots to follow) we now pass pointers to dummy arguments in
> those slots as a workaround.
Do you have any link to the detailed API reference to Apple's
Accelerate? I couldn't get any details for dsyev(r) by searching the web.
The canonical documentation for dsyevr should turn up by simply
googling "dsyevr", for example
http://www.netlib.org/lapack/explore-html/d2/d8a/group__double_s_yeigen_g...
http://www.netlib.org/lapack/lapack-3.1.1/html/dsyevr.f.html
It doesn't matter much for gretl after your workaround solves the
issue,
but in principle I guess it's not clear it is really a bug, perhaps they
just don't follow the netlib benchmark in this detail.
There may be no formally designated standard but I think most would
accept the netlib doc as the de facto standard.
I haven't found any formal documentation of the API for Apple's
lapack library (called by reference to the Accelerate Framework).
You may be right that they're not too bothered about adhering to the
netlib standard.
Once upon a time netlib lapack (version 3.2.1) had the same problem,
but that was fixed in the 3.2.2 release (June 2010) following a bug
report. See the comment on bug 0043 in
http://www.netlib.org/lapack/lapack-3.2.2.html
Allin