I am getting a seg fault from a package that I am working on, and I am totally flummoxed by it. The fault presumably arises from dynamically loaded Fortran code, but I'm damned if I can see where the error lies. In an effort to diagnose the problem I created a "non-package" version of the code. That is, I copied all the *.R files and *.f file into a new directory. In that directory I created a *.so file using R CMD SHLIB. In the R code I removed all the "PACKAGE=" lines from the calls to .Fortran() and put in appropriate dyn.load() calls. I then started R in this new "clean" directory and sourced all of the *.R files. I then issued the command that produces the seg fault when run under the aegis of the package. The command ran without a murmur of complaint. WTF? Can anyone suggest a reason why a seg fault might arise when the code is run in the context of a package, but not when it is run in "standalone mode"? I have checked and rechecked my init.c file --- which is the only thing that I can think of that might create a difference --- and cannot find any discrepancy between the declarations in the init.c file and the Fortran code. The package is a bit complicated, so giving more detail would be cumbersome. Also I have no idea what aspects of detail would be relevant. If anyone would like more info, feel free to ask. I would really appreciate it if someone could give me some suggestions before I go *completely* mad! cheers, Rolf Turner -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276
Rolf, have you tried to run R with a debugger, as in $ R -d gdb the gnu debugger? G, On 2018-08-11 23:12, Rolf Turner wrote:> > I am getting a seg fault from a package that I am working on, and I am > totally flummoxed by it.? The fault presumably arises from dynamically > loaded Fortran code, but I'm damned if I can see where the error lies. > > In an effort to diagnose the problem I created a "non-package" version > of the code.? That is, I copied all the *.R files and *.f file into a > new directory.? In that directory I created a *.so file using > R CMD SHLIB. > > In the R code I removed all the "PACKAGE=" lines from the calls to > .Fortran() and put in appropriate dyn.load() calls. > > I then started R in this new "clean" directory and sourced all of the > *.R files. > > I then issued the command that produces the seg fault when run under the > aegis of the package.? The command ran without a murmur of complaint. > WTF? > > Can anyone suggest a reason why a seg fault might arise when the code is > run in the context of a package, but not when it is run in "standalone > mode"? > > I have checked and rechecked my init.c file --- which is the only thing > that I can think of that might create a difference --- and cannot find > any discrepancy between the declarations in the init.c file and the > Fortran code. > > The package is a bit complicated, so giving more detail would be > cumbersome.? Also I have no idea what aspects of detail would be > relevant.? If anyone would like more info, feel free to ask. > > I would really appreciate it if someone could give me some suggestions > before I go *completely* mad! > > cheers, > > Rolf Turner >
Segfaults are not always repeatable. You may have an undefined pointer that sometime points into unreachable or unallocated memory, causing a segfault, and sometimes may point into valid memory, without causing a segfault. You may want to read https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access for tips on how to diagnose such problems. HTH, Peter On Sat, Aug 11, 2018 at 2:13 PM Rolf Turner <r.turner at auckland.ac.nz> wrote:> > I am getting a seg fault from a package that I am working on, and I am > totally flummoxed by it. The fault presumably arises from dynamically > loaded Fortran code, but I'm damned if I can see where the error lies. > > In an effort to diagnose the problem I created a "non-package" version > of the code. That is, I copied all the *.R files and *.f file into a > new directory. In that directory I created a *.so file using > R CMD SHLIB. > > In the R code I removed all the "PACKAGE=" lines from the calls to > .Fortran() and put in appropriate dyn.load() calls. > > I then started R in this new "clean" directory and sourced all of the > *.R files. > > I then issued the command that produces the seg fault when run under the > aegis of the package. The command ran without a murmur of complaint. > WTF? > > Can anyone suggest a reason why a seg fault might arise when the code is > run in the context of a package, but not when it is run in "standalone > mode"? > > I have checked and rechecked my init.c file --- which is the only thing > that I can think of that might create a difference --- and cannot find > any discrepancy between the declarations in the init.c file and the > Fortran code. > > The package is a bit complicated, so giving more detail would be > cumbersome. Also I have no idea what aspects of detail would be > relevant. If anyone would like more info, feel free to ask. > > I would really appreciate it if someone could give me some suggestions > before I go *completely* mad! > > cheers, > > Rolf Turner > > -- > Technical Editor ANZJS > Department of Statistics > University of Auckland > Phone: +64-9-373-7599 ext. 88276 > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >[[alternative HTML version deleted]]
Hi Rolf, When faced with such a situation I take the following approach which often helps. Use the same setup that caused the seg fault (you need a reproducible problem.) Start your R session using valgrind. e.g. in linux I do: $ valgrind R Assuming that a seg fault still occurs then valgrind should provide info as to where. HTH, Eric On Sun, Aug 12, 2018 at 5:13 AM, Peter Langfelder < peter.langfelder at gmail.com> wrote:> Segfaults are not always repeatable. You may have an undefined pointer that > sometime points into unreachable or unallocated memory, causing a segfault, > and sometimes may point into valid memory, without causing a segfault. > > You may want to read > https://cran.r-project.org/doc/manuals/r-release/R-exts. > html#Checking-memory-access > for tips on how to diagnose such problems. > > HTH, > > Peter > > On Sat, Aug 11, 2018 at 2:13 PM Rolf Turner <r.turner at auckland.ac.nz> > wrote: > > > > > I am getting a seg fault from a package that I am working on, and I am > > totally flummoxed by it. The fault presumably arises from dynamically > > loaded Fortran code, but I'm damned if I can see where the error lies. > > > > In an effort to diagnose the problem I created a "non-package" version > > of the code. That is, I copied all the *.R files and *.f file into a > > new directory. In that directory I created a *.so file using > > R CMD SHLIB. > > > > In the R code I removed all the "PACKAGE=" lines from the calls to > > .Fortran() and put in appropriate dyn.load() calls. > > > > I then started R in this new "clean" directory and sourced all of the > > *.R files. > > > > I then issued the command that produces the seg fault when run under the > > aegis of the package. The command ran without a murmur of complaint. > > WTF? > > > > Can anyone suggest a reason why a seg fault might arise when the code is > > run in the context of a package, but not when it is run in "standalone > > mode"? > > > > I have checked and rechecked my init.c file --- which is the only thing > > that I can think of that might create a difference --- and cannot find > > any discrepancy between the declarations in the init.c file and the > > Fortran code. > > > > The package is a bit complicated, so giving more detail would be > > cumbersome. Also I have no idea what aspects of detail would be > > relevant. If anyone would like more info, feel free to ask. > > > > I would really appreciate it if someone could give me some suggestions > > before I go *completely* mad! > > > > cheers, > > > > Rolf Turner > > > > -- > > Technical Editor ANZJS > > Department of Statistics > > University of Auckland > > Phone: +64-9-373-7599 ext. 88276 > > > > ______________________________________________ > > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > > https://stat.ethz.ch/mailman/listinfo/r-help > > PLEASE do read the posting guide > > http://www.R-project.org/posting-guide.html > > and provide commented, minimal, self-contained, reproducible code. > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/ > posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >[[alternative HTML version deleted]]
On 12/08/18 09:52, G?ran Brostr?m wrote:> Rolf, > > have you tried to run R with a debugger, as in > > $ R -d gdb > > the gnu debugger?No, I haven't. Did not know about the gnu debugger. I shall investigate. Thanks cheers, Rolf -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276