11:51 a.m.
Hello all,
It seems that running the following code crashes gretl in my computer.
For some reason more than 128 "series" less than 146 does not work in
the eigensym() command.
I am not sure if it is my computer or a "bug" ... or just me (i have a
feeling i am doing something terribly wrong..)
I run gretl on MS_windows (x86_64), 2015-10-19 version 2015d
Please find the code below (thanks for your time!!).
Note: when i change 129 to <=128 or to >=146 then it does not crash.
nulldata 600
setobs 1 1 --special-time-series
list xlist = null
loop i=1..129 --quiet
series x$i = normal()
xlist += x$i
endloop
scalar cT = $nobs
scalar cK = nelem(xlist)
matrix mX = {xlist}
mXdm = (mX .- meanc(mX))/cT
matrix XtX = (mXdm'mXdm)
matrix Ve0 = {} #ascending eigenvectors
matrix Va0 = eigensym( XtX , &Ve0 )
****************************************
Ioannis A. Venetis, Associate Professor
Director of Postgraduate Studies
University of Patras, School of Business Administration,
Department of Economics
University Campus, Rio, 26504, Greece
Tel: 0030 2610 969964
https://sites.google.com/site/ioannisavenetis/
****************************************
1:57 p.m.
Am 11.12.2015 um 12:51 schrieb Ioannis A. Venetis, Assoc. Prof.:
Hello all,
It seems that running the following code crashes gretl in my computer.
I can confirm the crash on Win 64 bit with the snapshot from Dec 8th.
I am not sure if it is my computer or a "bug" ... or just me (i have a
feeling i am doing something terribly wrong..)
At first sight your code looks perfectly normal, and in any case a
program crash is never really the user's fault.
cheers,
sven
2:02 p.m.
Hi all,
On Fri, Dec 11, 2015 at 1:57 PM, Sven Schreiber <svetosch(a)gmx.net> wrote:
Am 11.12.2015 um 12:51 schrieb Ioannis A. Venetis, Assoc. Prof.:
> Hello all,
>
> It seems that running the following code crashes gretl in my computer.
>
>
I can confirm the crash on Win 64 bit with the snapshot from Dec 8th.
I cannot reproduce in Linux x64 (Fedora 22) with latest Git (today).
Hélio
2:18 p.m.
On Fri, 11 Dec 2015, Sven Schreiber wrote:
Am 11.12.2015 um 12:51 schrieb Ioannis A. Venetis, Assoc. Prof.:
> Hello all,
>
> It seems that running the following code crashes gretl in my computer.
I can confirm the crash on Win 64 bit with the snapshot from Dec 8th.
>
> I am not sure if it is my computer or a "bug" ... or just me (i have a
> feeling i am doing something terribly wrong..)
At first sight your code looks perfectly normal, and in any case a
program crash is never really the user's fault.
Absolutely. And it's most unlikely that your computer is at fault.
However, I ran this code on 64-bit Linux under valgrind: no crash, and
no complaints from valgrind about memory management.
I suspect this may be a bug in openblas for 64-bit Windows (that's the
3rd party optimized BLAS/Lapack library that we use for things like
eigensym). I'll see what I can find out.
Ioannis, can you tell us exactly what kind of processor this computer
has? (Openblas contains several different processor-specific kernels,
so this may be useful information.)
Allin Cottrell
2:28 p.m.
-----Original Message-----
From: gretl-users-bounces(a)lists.wfu.edu [mailto:gretl-users-
bounces(a)lists.wfu.edu] On Behalf Of Allin Cottrell
Sent: Friday, December 11, 2015 9:18 AM
To: Gretl list
Subject: Re: [Gretl-users] eigensym() issue?
On Fri, 11 Dec 2015, Sven Schreiber wrote:
> Am 11.12.2015 um 12:51 schrieb Ioannis A. Venetis, Assoc. Prof.:
>> Hello all,
>>
>> It seems that running the following code crashes gretl in my computer.
>
> I can confirm the crash on Win 64 bit with the snapshot from Dec 8th.
Hmm. I get no crash on Win7 with 64-bit Gretl (2015e, build 11/30.
...
However, I ran this code on 64-bit Linux under valgrind: no crash,
and no
complaints from valgrind about memory management.
I suspect this may be a bug in openblas for 64-bit Windows (that's the 3rd
party optimized BLAS/Lapack library that we use for things like eigensym). I'll
see what I can find out.
Ioannis, can you tell us exactly what kind of processor this computer has?
(Openblas contains several different processor-specific kernels, so this may
be useful information.)
Allin Cottrell
In case it helps, I have an Intel Core i5-4690S, 3.2GHz
PS
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
2:38 p.m.
Am 11.12.2015 um 15:28 schrieb Summers, Peter:
> -----Original Message-----
> From: gretl-users-bounces(a)lists.wfu.edu [mailto:gretl-users-
> bounces(a)lists.wfu.edu] On Behalf Of Allin Cottrell
> Ioannis, can you tell us exactly what kind of processor this
computer has?
> (Openblas contains several different processor-specific kernels, so this may
> be useful information.)
>
> Allin Cottrell
In case it helps, I have an Intel Core i5-4690S, 3.2GHz
On this laptop with a crash observed there is a Core i5-3210M.
hth,
sven
3:39 p.m.
On 11/12/2015 15:38, Sven Schreiber wrote:
>> Ioannis, can you tell us exactly what kind of processor this
>> computer has?
>> (Openblas contains several different processor-specific kernels, so
>> this may
>> be useful information.)
>>
>> Allin Cottrell
> In case it helps, I have an Intel Core i5-4690S, 3.2GHz
On this laptop with a crash observed there is a Core i5-3210M.
hth,
sven
On my PC also crashes Gretl 2015e-git (2015/12/10) for MS Windows (x86_64) .
OS: Windows 10
Processor: Intel Core i7-3770S, 3.1 GHz
3:47 p.m.
On Fri, 11 Dec 2015, Allin Cottrell wrote:
>> I am not sure if it is my computer or a "bug" ...
or just me (i have a
>> feeling i am doing something terribly wrong..)
>
> At first sight your code looks perfectly normal, and in any case a program
> crash is never really the user's fault.
Absolutely. And it's most unlikely that your computer is at fault.
However, I ran this code on 64-bit Linux under valgrind: no crash, and no
complaints from valgrind about memory management.
Same here. If the problem was really the call to eigensym() the following
(simpler) code would probably trigger the same error. Could you please
check?
<hansl>
cT = 600
loop i=128..144 --quiet
matrix A = mnormal(cT, i)
A = (A .- meanc(A))/cT
matrix AA = A'A
matrix Ve0 = {} #ascending eigenvectors
matrix Va0 = eigensym( AA , &Ve0 )
endloop
</hansl>
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4:24 p.m.
On Fri, 11 Dec 2015, Ioannis A. Venetis, Assoc. Prof. wrote:
[Reporting a crash on 64-bit Windows when using the eigensym()
function on a matrix with dimension in the range 129 to 145 and
providing a script to provoke the problem.]
The crash was occurring in libopenblas.dll. I have now updated the
openblas library packaged in the 64-bit Windows build from version
0.2.14 to 0.2.16.dev. On my Core i7 laptop running Windows 8 that
fixes the problem. (I could replicate the crash when using the
previous openblas DLL; now the test script runs OK.)
Current snapshot at
http://gretl.sourceforge.net/win32/
Allin Cottrell
4:25 p.m.
Am 11.12.2015 um 17:24 schrieb Allin Cottrell:
The crash was occurring in libopenblas.dll. I have now updated the
openblas library packaged in the 64-bit Windows build from version
0.2.14 to 0.2.16.dev. On my Core i7 laptop running Windows 8 that fixes
the problem. (I could replicate the crash when using the previous
openblas DLL; now the test script runs OK.)
I hope the "dev" in the name doesn't mean that there are now new bugs
leading to unrelated crashes.... What I'm saying is, do your other test
scripts also run ok?
thanks,
sven
4:38 p.m.
On Fri, 11 Dec 2015, Sven Schreiber wrote:
Am 11.12.2015 um 17:24 schrieb Allin Cottrell:
>
> The crash was occurring in libopenblas.dll. I have now updated the
> openblas library packaged in the 64-bit Windows build from version
> 0.2.14 to 0.2.16.dev. On my Core i7 laptop running Windows 8 that fixes
> the problem. (I could replicate the crash when using the previous
> openblas DLL; now the test script runs OK.)
>
I hope the "dev" in the name doesn't mean that there are now new
bugs leading to unrelated crashes.... What I'm saying is, do your
other test scripts also run ok?
All my tests run OK with 0.2.16.dev on Linux.
Allin
5:15 p.m.
Am 11.12.2015 um 17:24 schrieb Allin Cottrell:
>
>> The crash was occurring in libopenblas.dll. I have now updated the
>> openblas library packaged in the 64-bit Windows build from version
>> 0.2.14 to 0.2.16.dev. On my Core i7 laptop running Windows 8 that fixes
>> the problem. (I could replicate the crash when using the previous
>> openblas DLL; now the test script runs OK.)
>
> I hope the "dev" in the name doesn't mean that there are now new bugs
> leading to unrelated crashes.... What I'm saying is, do your other
> test scripts also run ok?
All my tests run OK with 0.2.16.dev on Linux.
Allin
Now on my PC all works OK (Ioannis and Jack examples).
(Last Gretl 2015e-git (2015/12/11) for MS Windows (x86_64) , on Windows
10 with Intel Core i7-3770S, 3.1 GHz processor).
Juan C. Estévez
Santiago de Compostela
5:30 p.m.
On Fri, 11 Dec 2015, Allin Cottrell wrote:
On Fri, 11 Dec 2015, Sven Schreiber wrote:
> Am 11.12.2015 um 17:24 schrieb Allin Cottrell:
>
>>
>> The crash was occurring in libopenblas.dll. I have now updated the
>> openblas library packaged in the 64-bit Windows build from version
>> 0.2.14 to 0.2.16.dev. On my Core i7 laptop running Windows 8 that fixes
>> the problem. (I could replicate the crash when using the previous
>> openblas DLL; now the test script runs OK.)
>
> I hope the "dev" in the name doesn't mean that there are now new bugs
> leading to unrelated crashes.... What I'm saying is, do your other test
> scripts also run ok?
All my tests run OK with 0.2.16.dev on Linux.
I should add, before the next release (which should probably be
fairly soon) I'll look into this more carefully.
The fact that the crash occurred inside libopenblas.dll doesn't
actually prove that openblas was to blame. It's conceivable that
gretl was feeding duff arguments to the library -- although that
seems unlikely given that an openblas update fixed the problem.
I'll also check out the openblas changelog and see if there's a
"latest stable" version that contains the fix in question; we may
not want to be using a "dev" version if there's a good alternative.
Allin
3612
days inactive
3612
days old
13 comments
7 participants
participants (7)
-
Allin Cottrell -
Hélio Guilherme -
Ioannis A. Venetis, Assoc. Prof. -
Juan C. Estévez -
Riccardo (Jack) Lucchetti -
Summers, Peter -
Sven Schreiber