1:39 p.m.
El 4/3/22 a las 0:00, gretl-devel-request(a)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
4:45 p.m.
New subject: gretl crash
On Thu, 10 Mar 2022, Ignacio Diaz-Emparanza wrote:
El 4/3/22 a las 0:00, gretl-devel-request(a)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
9:15 a.m.
New subject: 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.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
1:43 p.m.
New subject: 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
5:14 p.m.
New subject: 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: 1111 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(a)gretlml.univpm.it
To unsubscribe send an email to gretl-devel-leave(a)gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
5:24 p.m.
New subject: 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
11:06 a.m.
New subject: 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
11:16 a.m.
New subject: 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
1:39 p.m.
New subject: 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
1:46 p.m.
New subject: 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
3:27 p.m.
New subject: 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
1022
days inactive
1026
days old
10 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Marcin Błażejowski -
Riccardo (Jack) Lucchetti