[Gretl-devel] Re: gretl crash with omitted arg in hansl function
Am 10.07.2023 um 19:18 schrieb Sven Schreiber:
I'm seeing the following reproducible crash on Windows 10 on a
snapshot from May. (Later I will test on a newer snapshot, but maybe
someone can reproduce this.)
Here's a pretty minimal example:
function matrix f (string name[null])
print "hello"
return I(2)
end function
f()
f("aha")
Just a quick confirmation that in the July-14th snapshot this is fixed.
thanks
sven
___
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash with omitted arg in hansl function
On Mon, Jul 10, 2023 at 2:53 PM Cottrell, Allin wrote:
>
> On Mon, Jul 10, 2023 at 1:18 PM Sven Schreiber
> wrote:
> >
> > I'm seeing the following reproducible crash on Windows 10 on a snapshot
> > from May. (Later I will test on a newer snapshot, but maybe someone can
> > reproduce this.)
> >
> > Here's a pretty minimal example:
> >
> >
> > function matrix f (string name[null])
> > print "hello"
> > return I(2)
> > end function
> >
> > f()
> > f("aha")
> >
>
> Hmm, it's the second call, with @name supplied, that's actually
> triggering the crash -- but only in the context of the previous empty
> call. So something is not being initialized/reset properly when the
> empty call exits. Should be a fairly straightforward fix, I think.
That's fixed now in git.
Allin
___
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash with omitted arg in hansl function
On Mon, Jul 10, 2023 at 1:18 PM Sven Schreiber
wrote:
>
> I'm seeing the following reproducible crash on Windows 10 on a snapshot
> from May. (Later I will test on a newer snapshot, but maybe someone can
> reproduce this.)
>
> Here's a pretty minimal example:
>
>
> function matrix f (string name[null])
> print "hello"
> return I(2)
> end function
>
> f()
> f("aha")
>
Hmm, it's the second call, with @name supplied, that's actually
triggering the crash -- but only in the context of the previous empty
call. So something is not being initialized/reset properly when the
empty call exits. Should be a fairly straightforward fix, I think.
Allin
___
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash with omitted arg in hansl function
On Mon, 10 Jul 2023, Sven Schreiber wrote: Hi, I'm seeing the following reproducible crash on Windows 10 on a snapshot from May. (Later I will test on a newer snapshot, but maybe someone can reproduce this.) Confirmed on current git in Linux. --- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucche...@univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti ---___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
El 14/3/22 a las 14:39, Allin Cottrell escribió: On Mon, 14 Mar 2022, Ignacio Diaz-Emparanza wrote: Well, ... I don't know if this may help much. I reinstalled gretl from git and tried to run the script, this is the output in the terminal: The R library path '/usr/lib/libR.so' seems to be a symlink resolved to 'R/lib/libR.so' cannot find system Renviron Fatal error: unable to open the base package BTW, in my system the link in /usr/lib is libR.so -> R/lib/libR.so so, that is pointing to the absolute path /usr/lib/R/lib/libR.so That certainly helps. Now I get it: your libR.so path is a _relative_ symlink where I had been expecting an absolute one. In git there's now code to handle the relative case. Allin Yes, it worked!! The crash is solved. Thank you. Ignacio ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On 14.03.2022 14:39, Allin Cottrell wrote: That certainly helps. Now I get it: your libR.so path is a _relative_ symlink where I had been expecting an absolute one. In git there's now code to handle the relative case. Allin, I'm getting the following: ../../lib/src/gretl_foreign.c: In function ‘absolutize_R_path’: ../../lib/src/gretl_foreign.c:2365:50: error: ‘tmp’ undeclared (first use in this function); did you mean ‘tm’? 2365 | fprintf(stderr, " absolute path '%s'\n", tmp); | ^~~ | tm Marcin -- Marcin Błażejowski ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Mon, 14 Mar 2022, Ignacio Diaz-Emparanza wrote: > > Well, ... I don't know if this may help much. I reinstalled gretl from git > > and tried to run the script, this is the output in the terminal: > > > > The R library path '/usr/lib/libR.so' seems to be a symlink > > resolved to 'R/lib/libR.so' > > cannot find system Renviron > > Fatal error: unable to open the base package > > > > > BTW, in my system the link in /usr/lib is > > libR.so -> R/lib/libR.so > > so, that is pointing to the absolute path /usr/lib/R/lib/libR.so That certainly helps. Now I get it: your libR.so path is a _relative_ symlink where I had been expecting an absolute one. In git there's now code to handle the relative case. Allin___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
El 14/3/22 a las 12:06, Ignacio Diaz-Emparanza escribió: El 13/3/22 a las 18:24, Allin Cottrell escribió: On Sun, 13 Mar 2022, Ignacio Diaz-Emparanza wrote: Hi, the changes you (Allin) made to gretl in git seem not to work. If I don't set the environment variable up, I continue to obtain the crash. This is the output of valgrind (I assume you only need the last part) [...] Thanks, Ignacio, but valgrind is no help here. Could you post what appears on stderr from running gretl, please? That is, run gretl from a terminal window and see what gets printed. I've just pushed a small change to git which might help with the diagnostics. Allin Well, ... I don't know if this may help much. I reinstalled gretl from git and tried to run the script, this is the output in the terminal: The R library path '/usr/lib/libR.so' seems to be a symlink resolved to 'R/lib/libR.so' cannot find system Renviron Fatal error: unable to open the base package BTW, in my system the link in /usr/lib is libR.so -> R/lib/libR.so so, that is pointing to the absolute path /usr/lib/R/lib/libR.so Ignacio ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
El 13/3/22 a las 18:24, Allin Cottrell escribió: On Sun, 13 Mar 2022, Ignacio Diaz-Emparanza wrote: Hi, the changes you (Allin) made to gretl in git seem not to work. If I don't set the environment variable up, I continue to obtain the crash. This is the output of valgrind (I assume you only need the last part) [...] Thanks, Ignacio, but valgrind is no help here. Could you post what appears on stderr from running gretl, please? That is, run gretl from a terminal window and see what gets printed. I've just pushed a small change to git which might help with the diagnostics. Allin Well, ... I don't know if this may help much. I reinstalled gretl from git and tried to run the script, this is the output in the terminal: The R library path '/usr/lib/libR.so' seems to be a symlink resolved to 'R/lib/libR.so' cannot find system Renviron Fatal error: unable to open the base package ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Sun, 13 Mar 2022, Ignacio Diaz-Emparanza wrote: Hi, the changes you (Allin) made to gretl in git seem not to work. If I don't set the environment variable up, I continue to obtain the crash. This is the output of valgrind (I assume you only need the last part) [...] Thanks, Ignacio, but valgrind is no help here. Could you post what appears on stderr from running gretl, please? That is, run gretl from a terminal window and see what gets printed. I've just pushed a small change to git which might help with the diagnostics. Allin ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
Hi, the changes you (Allin) made to gretl in git seem not to work. If I don't set the environment variable up, I continue to obtain the crash. This is the output of valgrind (I assume you only need the last part) [...] ==2059846== by 0x1F321B: gui_exec_line (library.c:10759) ==2059846== Address 0x1ffefd93ab is on thread 1's stack ==2059846== in frame #3, created by buffered_vfprintf (vfprintf-internal.c:2345) ==2059846== resolved to 'R/lib/libR.soB+�' cannot find system Renviron Fatal error: unable to open the base package ==2059846== ==2059846== HEAP SUMMARY: ==2059846== in use at exit: 13,857,526 bytes in 102,329 blocks ==2059846== total heap usage: 896,320 allocs, 793,991 frees, 84,031,037 bytes allocated ==2059846== ==2059846== LEAK SUMMARY: ==2059846== definitely lost: 30,776 bytes in 41 blocks ==2059846== indirectly lost: 50,779 bytes in 2,182 blocks ==2059846== possibly lost: 7,244 bytes in 67 blocks ==2059846== still reachable: 12,239,855 bytes in 89,702 blocks ==2059846== of which reachable via heuristic: ==2059846== length64 : 10,008 bytes in 150 blocks ==2059846== newarray : 2,288 bytes in 63 blocks ==2059846== suppressed: 0 bytes in 0 blocks ==2059846== Rerun with --leak-check=full to see details of leaked memory ==2059846== ==2059846== Use --track-origins=yes to see where uninitialised values come from ==2059846== For lists of detected and suppressed errors, rerun with: -s ==2059846== ERROR SUMMARY: errors from 31 contexts (suppressed: 0 from 0) El 12/3/22 a las 14:43, Allin Cottrell escribió: On Sat, 12 Mar 2022, Riccardo (Jack) Lucchetti wrote: On Fri, 11 Mar 2022, Allin Cottrell wrote: If someone could give me the exact steps to run gretl with "gdb" I can try to do it. Thanks, Ignacio. Here are the steps: [...] valgrind can be another option for tracing the problem. Just install valgrind and issue the command valgrind /usr/bin/gretl_x11 your_script.inp Execution will be _very_ slow, but if you get a crash you should receive a list of the internal functions that led to it. Valgrind can be very helpful in general, but this case is special. I'm pretty sure it's not a "true" crash -- I believe that the libR code is calling abort() when it can't find Renviron (because it doesn't know the value of R_HOME). And when abort is called by a library, the program that loaded the library is automatically terminated. This is consistent with the fact that Ignacio couldn't get a backtrace from gdb: gretl didn't segfault, it just exited. Allin ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/ ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Sat, 12 Mar 2022, Riccardo (Jack) Lucchetti wrote: On Fri, 11 Mar 2022, Allin Cottrell wrote: If someone could give me the exact steps to run gretl with "gdb" I can try to do it. Thanks, Ignacio. Here are the steps: [...] valgrind can be another option for tracing the problem. Just install valgrind and issue the command valgrind /usr/bin/gretl_x11 your_script.inp Execution will be _very_ slow, but if you get a crash you should receive a list of the internal functions that led to it. Valgrind can be very helpful in general, but this case is special. I'm pretty sure it's not a "true" crash -- I believe that the libR code is calling abort() when it can't find Renviron (because it doesn't know the value of R_HOME). And when abort is called by a library, the program that loaded the library is automatically terminated. This is consistent with the fact that Ignacio couldn't get a backtrace from gdb: gretl didn't segfault, it just exited. Allin ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Fri, 11 Mar 2022, Allin Cottrell wrote: If someone could give me the exact steps to run gretl with "gdb" I can try to do it. Thanks, Ignacio. Here are the steps: [...] valgrind can be another option for tracing the problem. Just install valgrind and issue the command valgrind /usr/bin/gretl_x11 your_script.inp Execution will be _very_ slow, but if you get a crash you should receive a list of the internal functions that led to it. --- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucche...@univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti ---___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Thu, 10 Mar 2022, Ignacio Diaz-Emparanza wrote: El 4/3/22 a las 0:00, gretl-devel-requ...@gretlml.univpm.it escribió: On Tue, 1 Mar 2022, Allin Cottrell wrote: I think I see what's happening. On my system I have the environment variable R_HOME set to "/opt/R/lib64/R". I guess in your case that variable is not set. So I suspect the following: if you pass the actual path to libR.so, gretl can infer where R_HOME is and all is OK. If you pass a symlink and R_HOME is NOT set, R doesn't know where its files are and gretl can't help. Anyway, it seems clear that the crash is in libR.so, which can't find "Renviron" under the stated conditions: called via symlink with R_HOME undefined. Maybe gretl could help with some fancy footwork, using the OS to resolve a libR symlink. That "fancy footwork" is now in git. We detect the case where the user-specified path to libR.so is a symlink; resolve the symlink to find the "real" path to libR.so; use that path to figure out where R_HOME is; and put the correct value of R_HOME into the environment so that libR can find the files without which it will crash. I tested this on Fedora Linux, after removing R_HOME from my environment and replacing the "real" libR location in my gretl Preferences with the path to a symlink in /usr/local/lib. Allin I am very sorry for this delay. I was able to check it today and it doesn't work. I updated gretl from git, changed the path as it was originally (/usr/lib/libR.so), but still get the same crash. If someone could give me the exact steps to run gretl with "gdb" I can try to do it. Thanks, Ignacio. Here are the steps: 1) Call gdb with argument the path to the gretl executable, as in gdb /usr/bin/gretl_x11 2) Use the "set args" command within gdb to specify a script to run, as in (gdb) set args /path/to/script.inp 3) Call the "run" command in gdb: (gdb) run You should now see some spew from gdb, presumably terminating with a crash in the case under discussion. Then 4) Use gdb's "bt" command to get a backtrace: (gdb) bt This should give us some idea of where the problem lies. Allin___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
El 4/3/22 a las 0:00, gretl-devel-requ...@gretlml.univpm.it escribió: On Tue, 1 Mar 2022, Allin Cottrell wrote: I think I see what's happening. On my system I have the environment variable R_HOME set to "/opt/R/lib64/R". I guess in your case that variable is not set. So I suspect the following: if you pass the actual path to libR.so, gretl can infer where R_HOME is and all is OK. If you pass a symlink and R_HOME is NOT set, R doesn't know where its files are and gretl can't help. Anyway, it seems clear that the crash is in libR.so, which can't find "Renviron" under the stated conditions: called via symlink with R_HOME undefined. Maybe gretl could help with some fancy footwork, using the OS to resolve a libR symlink. That "fancy footwork" is now in git. We detect the case where the user-specified path to libR.so is a symlink; resolve the symlink to find the "real" path to libR.so; use that path to figure out where R_HOME is; and put the correct value of R_HOME into the environment so that libR can find the files without which it will crash. I tested this on Fedora Linux, after removing R_HOME from my environment and replacing the "real" libR location in my gretl Preferences with the path to a symlink in /usr/local/lib. Allin I am very sorry for this delay. I was able to check it today and it doesn't work. I updated gretl from git, changed the path as it was originally (/usr/lib/libR.so), but still get the same crash. If someone could give me the exact steps to run gretl with "gdb" I can try to do it. Ignacio -- Ignacio Díaz-Emparanza Departamento de Métodos Cuantitativos Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU Tfno: (+34) 94 601 3732 ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Tue, 1 Mar 2022, Allin Cottrell wrote: I think I see what's happening. On my system I have the environment variable R_HOME set to "/opt/R/lib64/R". I guess in your case that variable is not set. So I suspect the following: if you pass the actual path to libR.so, gretl can infer where R_HOME is and all is OK. If you pass a symlink and R_HOME is NOT set, R doesn't know where its files are and gretl can't help. Anyway, it seems clear that the crash is in libR.so, which can't find "Renviron" under the stated conditions: called via symlink with R_HOME undefined. Maybe gretl could help with some fancy footwork, using the OS to resolve a libR symlink. That "fancy footwork" is now in git. We detect the case where the user-specified path to libR.so is a symlink; resolve the symlink to find the "real" path to libR.so; use that path to figure out where R_HOME is; and put the correct value of R_HOME into the environment so that libR can find the files without which it will crash. I tested this on Fedora Linux, after removing R_HOME from my environment and replacing the "real" libR location in my gretl Preferences with the path to a symlink in /usr/local/lib. Allin ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Tue, 1 Mar 2022, Ignacio Diaz-Emparanza wrote: Reporting about the gretl crash: 1) I changed "Use local setting for decimal point" to "on" in my laptop (Ubuntu 20.04 and gretl built on 2022-02-25). StrucTs script worked without problem. 2) Now I changed "Use local setting for decimal point" to "off" in my office's desktop PC (Ubuntu 20.04 and gretl built on 2022-02-23). StructTs script makes gretl crash (the same as with the option in "on". 3) I had a look to gdb (I don't have valgrind installed) but ... now I am not a so advanced linux user. 4) I run the script in a terminal with gretlcli obtaining a halt with this error: "cannot find system Renviron. Fatal error: unable to open the base package". I go to gretl preferences and in "Path to R library" I see "/usr/lib/libR.so" 5) I open a terminal and go to /usr/lib to see if the file exists, yes it exists. The output of ls -ll libR* is lrwxrwxrwx 1 root root 13 nov 2 22:13 libR.so -> R/lib/libR.so I check with a "cat" if the link is working at it is. The original "real" place of libR.so is /usr/lib/R/lib/libR.so 6) I go to gretl's preferences again and change the R library path to /usr/lib/R/lib/libR.so, I try to run the script again and... it works! My conclusion: what is causing the crash is the soft link. Don't ask me why I had a path to this soft link. No idea. Thanks for following up on this, Ignacio. The problem is not a soft link as such. In my gretl preferences I had the path to libR.so set to the actual path on my system, namely /opt/R/lib64/R/lib/libR.so. As an experiment, I created a symlink /usr/local/lib/libR.so and changed my gretl preferences to point to the symlink. I then ran gretl in Spanish, both with and without the locale decimal character option, and everything worked OK. However, I think I see what's happening. On my system I have the environment variable R_HOME set to "/opt/R/lib64/R". I guess in your case that variable is not set. So I suspect the following: if you pass the actual path to libR.so, gretl can infer where R_HOME is and all is OK. If you pass a symlink and R_HOME is NOT set, R doesn't know where its files are and gretl can't help. Anyway, it seems clear that the crash is in libR.so, which can't find "Renviron" under the stated conditions: called via symlink with R_HOME undefined. Maybe gretl could help with some fancy footwork, using the OS to resolve a libR symlink. Allin___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Tue, 1 Mar 2022, Ignacio Diaz-Emparanza wrote: My conclusion: what is causing the crash is the soft link. Don't ask me why I had a path to this soft link. No idea. Well, that IS puzzling. From gretl's point of view a soft link to a library is no different from the actual .so file. I am perplexed. --- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucche...@univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti ---___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
Reporting about the gretl crash: 1) I changed "Use local setting for decimal point" to "on" in my laptop (Ubuntu 20.04 and gretl built on 2022-02-25). StrucTs script worked without problem. 2) Now I changed "Use local setting for decimal point" to "off" in my office's desktop PC (Ubuntu 20.04 and gretl built on 2022-02-23). StructTs script makes gretl crash (the same as with the option in "on". 3) I had a look to gdb (I don't have valgrind installed) but ... now I am not a so advanced linux user. 4) I run the script in a terminal with gretlcli obtaining a halt with this error: "cannot find system Renviron. Fatal error: unable to open the base package". I go to gretl preferences and in "Path to R library" I see "/usr/lib/libR.so" 5) I open a terminal and go to /usr/lib to see if the file exists, yes it exists. The output of ls -ll libR* is lrwxrwxrwx 1 root root 13 nov 2 22:13 libR.so -> R/lib/libR.so I check with a "cat" if the link is working at it is. The original "real" place of libR.so is /usr/lib/R/lib/libR.so 6) I go to gretl's preferences again and change the R library path to /usr/lib/R/lib/libR.so, I try to run the script again and... it works! My conclusion: what is causing the crash is the soft link. Don't ask me why I had a path to this soft link. No idea. -- Ignacio Díaz-Emparanza Departamento de Métodos Cuantitativos Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU Tfno: (+34) 94 601 3732 ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Thu, 24 Feb 2022, Ignacio Diaz-Emparanza wrote: Thank you Jack, for trying it, but it seems this is not the problem. I fixed the indentation and gretl continues crashing. I am sending the file for whether you can see another strange character. (I don't understand the output of hexdump) The file you attached runs fine here. --- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucche...@univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti ---___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
El 24/2/22 a las 16:57, gretl-devel-requ...@gretlml.univpm.it escribió:
[...]The version of R seems not to affect. I just upgraded from R 3.6
to 4.1.2 obtaining the same crash.
I have gretl 2001.c built on august in my laptop (ubuntu 20.04 as
well), and this script may be run without problem.
OK, two things. Copy-n-pasting Ignacio's script provokes some weird
hiccup on mu system because of the indentation (those are not spaces
nor tabs; God knows what they are. Hexdump gives me "c2 a0"; go figure).
After fixing the indentation, the script runs fine here. Still, a
crash should never happen.
Thank you Jack, for trying it, but it seems this is not the problem. I
fixed the indentation and gretl continues crashing. I am sending the
file for whether you can see another strange character. (I don't
understand the output of hexdump)
A few extra points:
* The script in fact comes from the User's Guide (chap. 44), not the
Hansl Primer. Copy-pasting code from the pdf files will give you
nothing but trouble. This is why recent versions of the User's Guide
have clickable links to download the example scripts.
Yes, sorry, I was alternating between the two and I must have been
wrong. It's the chapter about R and gretl. I can see now the link to
download the script.
* Not really relevant but... for that kind of stuff (structural time
series models) it's not necessary to go throuh R anymore, since we
have the StrucTiSM package ;)
Yes, but it is a good example on how to play jointly with gretl and R
* Even less relevant, but... Ignacio: we would value very much your
opinion on the new GUI element for setting up state space models. A
model like the one in the example (a Local Linear Trend model) is
quite easy to handle.
I haven't had a chance to review it yet. I haven't used models in state
space form lately. But I hope to be able to do it soon.
--
Ignacio Díaz-Emparanza
Departamento de Métodos Cuantitativos
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732
open bjg.gdt
foreign language=R --send-data
y <- gretldata[, "lg"]
strmod <- StructTS(y)
compon <- as.ts(tsSmooth(strmod))
vars <- as.matrix(strmod$coef)
gretl.export(compon)
gretl.export(vars)
end foreign
append @dotdir/compon.csv
rename level lg_level
rename slope lg_slope
rename sea lg_seas
vars = mread("vars.mat", 1)
___
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Thu, 24 Feb 2022, Ignacio Diaz-Emparanza wrote:
> I'm getting a reproducible crash when trying to run on my desktop (Ubuntu
> linux 20.04 and gretl built yesterday from git)the following script(which is
> as is in the "Hansl Primer" guide):
>
>
>
> open bjg.gdt
> foreign language=R --send-data
> y <- gretldata[, "lg"]
> strmod <- StructTS(y)
> compon <- as.ts(tsSmooth(strmod))
> vars <- as.matrix(strmod$coef)
> gretl.export(compon)
> gretl.export(vars)
> end foreign
> append @dotdir/compon.csv
> rename level lg_level
> rename slope lg_slope
> rename sea lg_seas
>
> vars = mread("vars.mat", 1)
>
>
>
> The version of R seems not to affect. I just upgraded from R 3.6 to 4.1.2
> obtaining the same crash.
>
> I have gretl 2001.c built on august in my laptop (ubuntu 20.04 as well), and
> this script may be run without problem.
I can't produce a crash on Arch Linux, but I'm seeing a problem if I
run in Spanish with the decimal comma selected: the CSV file written
by R is broken, since it uses comma as both the column separator
and the decimal character. That should be easy enough to fix.
Allin___
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
On Thu, 24 Feb 2022, Ignacio Diaz-Emparanza wrote:
I'm getting a reproducible crash when trying to run on my desktop (Ubuntu
linux 20.04 and gretl built yesterday from git)the following script(which is
as is in the "Hansl Primer" guide):
open bjg.gdt
foreign language=R --send-data
y <- gretldata[, "lg"]
strmod <- StructTS(y)
compon <- as.ts(tsSmooth(strmod))
vars <- as.matrix(strmod$coef)
gretl.export(compon)
gretl.export(vars)
end foreign
append @dotdir/compon.csv
rename level lg_level
rename slope lg_slope
rename sea lg_seas
vars = mread("vars.mat", 1)
The version of R seems not to affect. I just upgraded from R 3.6 to 4.1.2
obtaining the same crash.
I have gretl 2001.c built on august in my laptop (ubuntu 20.04 as well), and
this script may be run without problem.
OK, two things. Copy-n-pasting Ignacio's script provokes some weird hiccup
on mu system because of the indentation (those are not spaces nor tabs;
God knows what they are. Hexdump gives me "c2 a0"; go figure).
After fixing the indentation, the script runs fine here. Still, a crash
should never happen.
A few extra points:
* The script in fact comes from the User's Guide (chap. 44), not the Hansl
Primer. Copy-pasting code from the pdf files will give you nothing but
trouble. This is why recent versions of the User's Guide have clickable
links to download the example scripts.
* Not really relevant but... for that kind of stuff (structural time
series models) it's not necessary to go throuh R anymore, since we have
the StrucTiSM package ;)
* Even less relevant, but... Ignacio: we would value very much your
opinion on the new GUI element for setting up state space models. A model
like the one in the example (a Local Linear Trend model) is quite easy to
handle.
---
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucche...@univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
---___
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash
Am 24.02.2022 um 15:25 schrieb Ignacio Diaz-Emparanza: I'm getting a reproducible crash when trying to run on my desktop (Ubuntu linux 20.04 and gretl built yesterday from git)the following script(which is as is in the "Hansl Primer" guide): Just as an additional datapoint, I can run the script OK on Windows with the Feb9-snapshot. thanks sven ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash after 'hausman'
Am 11.07.2021 22:52 schrieb Allin Cottrell: On Sun, 11 Jul 2021, Sven Schreiber wrote: - open abdata and estimate something with OLS - run hausman - execute 'print $test' (which produces NA) Not having $test available in this case seems a bit lame. In git I've made $test and $pvalue available as 3-vectors following "hausman". The three tests are in the order shown in the printout: 1 Wald test for poolability in relation to fixed effects. 2 Breusch-Pagan test for poolability in relation to random effects. 3 The Hausman test itself. If this behavior seems OK I can document it. (Maybe there's a case for just giving the Hausman test result?) Hi Allin, in case the decision is to keep this feature, I suggest to add row labels. Currently the output is just open grunfeld ols invest const value hausman eval $test ? eval $test 15.974 273.16 3.8110 and the user (ok, at least me :-) ) would have to consult the document each time checking which row refers to what. Best, Artur ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash after 'hausman'
Am 11.07.2021 um 22:52 schrieb Allin Cottrell: On Sun, 11 Jul 2021, Sven Schreiber wrote: - open abdata and estimate something with OLS - run hausman - execute 'print $test' (which produces NA) Not having $test available in this case seems a bit lame. In git I've made $test and $pvalue available as 3-vectors following "hausman". The three tests are in the order shown in the printout: I think in principle having these accessors here is good, yes. (This looks a bit like phasing out the usage of the special accessor $hausman at least in the panel context, which I'd see as further harmonization, a good thing IMO.) 1 Wald test for poolability in relation to fixed effects. 2 Breusch-Pagan test for poolability in relation to random effects. Couldn't these be done as "modtest --poolability" or something? 3 The Hausman test itself. If this behavior seems OK I can document it. (Maybe there's a case for just giving the Hausman test result?) Yes, I tend to think it's better to separate those things. The Hausman test principle is very general, but Wald or LM tests are different, so I'd say it gets confusing when those have to be invoked by a "hausman" command. The other way around: the Hausman result in the narrow sense could also be returned as part of a new "modtest --poolability". thanks sven ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash after 'hausman'
On Sun, 11 Jul 2021, Sven Schreiber wrote: - open abdata and estimate something with OLS - run hausman - execute 'print $test' (which produces NA) Not having $test available in this case seems a bit lame. In git I've made $test and $pvalue available as 3-vectors following "hausman". The three tests are in the order shown in the printout: 1 Wald test for poolability in relation to fixed effects. 2 Breusch-Pagan test for poolability in relation to random effects. 3 The Hausman test itself. If this behavior seems OK I can document it. (Maybe there's a case for just giving the Hausman test result?) Allin ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[Gretl-devel] Re: gretl crash after 'hausman'
On Sun, 11 Jul 2021, Sven Schreiber wrote: ...just after sending the last message gretl crashed on me, and it's reproducible (in the console): - open abdata and estimate something with OLS - run hausman - execute 'print $test' (which produces NA) - run hausman again -> crash Thanks for the report. That's now fixed in git. I haven't updated the snapshots just yet because some new stuff needs more testing first. Allin ___ Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
