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 17:42, Eric Berger wrote:> 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. > > HTHWell, it probably *would* help if I weren't such a thicko. The story so far: I have managed to install valgrind (downloaded a tarball and installed from source). Seemed to go OK, but: * when I type "valgrind" I get "command not found" * however valgrind is in /usr/local/bin (I did "configure" with prefix="/usr/local" so this is as it should be) * /usr/local/bin/valgrind is executable * /usr/local/bin is in my path So how in god's name can the command not be found? And why do these things always happen to *me*??? I can work around this problem by giving the full path name, however. So I did: /usr/local/bin/valgrind R and got a lot of (mysterious to me) output:> /usr/local/bin/valgrind R > ==18051== Memcheck, a memory error detector > ==18051== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==18051== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info > ==18051== Command: /usr/local/bin/R > ==18051== > ==18051== Invalid free() / delete / delete[] / realloc() > ==18051== at 0x4C2ECF0: free (vg_replace_malloc.c:530) > ==18051== by 0x45E280: ??? (in /bin/bash) > ==18051== by 0x45E42F: run_unwind_frame (in /bin/bash) > ==18051== by 0x47B714: parse_and_execute (in /bin/bash) > ==18051== by 0x47B102: ??? (in /bin/bash) > ==18051== by 0x47B35C: source_file (in /bin/bash) > ==18051== by 0x4849C7: source_builtin (in /bin/bash) > ==18051== by 0x43378D: ??? (in /bin/bash) > ==18051== by 0x43592C: ??? (in /bin/bash) > ==18051== by 0x4369C7: execute_command_internal (in /bin/bash) > ==18051== by 0x43851D: execute_command (in /bin/bash) > ==18051== by 0x42139D: reader_loop (in /bin/bash) > ==18051== Address 0x4241008 is in the brk data segment 0x4228000-0x4246fff > ==18051== > ==18051== Invalid free() / delete / delete[] / realloc() > ==18051== at 0x4C2ECF0: free (vg_replace_malloc.c:530) > ==18051== by 0x45E280: ??? (in /bin/bash) > ==18051== by 0x45E42F: run_unwind_frame (in /bin/bash) > ==18051== by 0x4849D3: source_builtin (in /bin/bash) > ==18051== by 0x43378D: ??? (in /bin/bash) > ==18051== by 0x43592C: ??? (in /bin/bash) > ==18051== by 0x4369C7: execute_command_internal (in /bin/bash) > ==18051== by 0x43851D: execute_command (in /bin/bash) > ==18051== by 0x42139D: reader_loop (in /bin/bash) > ==18051== by 0x41FDB0: main (in /bin/bash) > ==18051== Address 0x4240708 is in the brk data segment 0x4228000-0x4246fff > ==18051== >Not at all clear to me what to make of this. Does it indicate problems or memory leaks in my installation of R? Anyhow, things then proceed in an expected manner:> R version 3.5.1 (2018-07-02) -- "Feather Spray" > Copyright (C) 2018 The R Foundation for Statistical Computing > Platform: x86_64-pc-linux-gnu (64-bit) > > R is free software and comes with ABSOLUTELY NO WARRANTY. > You are welcome to redistribute it under certain conditions. > Type 'license()' or 'licence()' for distribution details. > > Natural language support but running in an English locale > > R is a collaborative project with many contributors. > Type 'contributors()' for more information and > 'citation()' on how to cite R or R packages in publications. > > Type 'demo()' for some demos, 'help()' for on-line help, or > 'help.start()' for an HTML browser interface to help. > Type 'q()' to quit R. > > Loading required package: misc > [Previously saved workspace restored]I then loaded the problematic package and issued the problematic command:> > library(hmm.discnp) > hmm.discnp 2.0-9 > > This package has changed SUBSTANTIALLY from its > previous release. Read the documentation > carefully. Note in particular that the meaning of > the argument "nsim" of the function rhmm() has > changed, and a new argument "ylengths" now plays > essentially the role previously played by > "nsim". > > > xxx <- get.hgl(p3,2,yyy) > > *** caught segfault *** > address (nil), cause 'unknown' > Segmentation fault (core dumped)Nothing informative. Is there something else I should be doing? Sorry for being a nuisance, but I am at a loss. cheers, Rolf -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276
On 12/08/2018 6:32 PM, Rolf Turner wrote:> > On 12/08/18 17:42, Eric Berger wrote: > >> 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 > > Well, it probably *would* help if I weren't such a thicko. > > The story so far: I have managed to install valgrind (downloaded a > tarball and installed from source). Seemed to go OK, but: > > * when I type "valgrind" I get "command not found" > * however valgrind is in /usr/local/bin (I did "configure" with > prefix="/usr/local" so this is as it should be) > * /usr/local/bin/valgrind is executable > * /usr/local/bin is in my path > > So how in god's name can the command not be found? And why do these > things always happen to *me*??? > > I can work around this problem by giving the full path name, however. > > So I did: > > /usr/local/bin/valgrind RI believe on your system R is a script, so you can't run valgrind this way. It's just debugging bash, not R. You need to use R -d valgrind (though with your weird path problems, you might need a fully qualified /usr/local/bin/valgrind there). You run gdb the same way: R -d gdb and then give the command "r" to gdb to start R. It will give a report when you get the segfault. I don't know which report will be more informative. Duncan Murdoch> > and got a lot of (mysterious to me) output: > >> /usr/local/bin/valgrind R >> ==18051== Memcheck, a memory error detector >> ==18051== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. >> ==18051== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info >> ==18051== Command: /usr/local/bin/R >> ==18051=>> ==18051== Invalid free() / delete / delete[] / realloc() >> ==18051== at 0x4C2ECF0: free (vg_replace_malloc.c:530) >> ==18051== by 0x45E280: ??? (in /bin/bash) >> ==18051== by 0x45E42F: run_unwind_frame (in /bin/bash) >> ==18051== by 0x47B714: parse_and_execute (in /bin/bash) >> ==18051== by 0x47B102: ??? (in /bin/bash) >> ==18051== by 0x47B35C: source_file (in /bin/bash) >> ==18051== by 0x4849C7: source_builtin (in /bin/bash) >> ==18051== by 0x43378D: ??? (in /bin/bash) >> ==18051== by 0x43592C: ??? (in /bin/bash) >> ==18051== by 0x4369C7: execute_command_internal (in /bin/bash) >> ==18051== by 0x43851D: execute_command (in /bin/bash) >> ==18051== by 0x42139D: reader_loop (in /bin/bash) >> ==18051== Address 0x4241008 is in the brk data segment 0x4228000-0x4246fff >> ==18051=>> ==18051== Invalid free() / delete / delete[] / realloc() >> ==18051== at 0x4C2ECF0: free (vg_replace_malloc.c:530) >> ==18051== by 0x45E280: ??? (in /bin/bash) >> ==18051== by 0x45E42F: run_unwind_frame (in /bin/bash) >> ==18051== by 0x4849D3: source_builtin (in /bin/bash) >> ==18051== by 0x43378D: ??? (in /bin/bash) >> ==18051== by 0x43592C: ??? (in /bin/bash) >> ==18051== by 0x4369C7: execute_command_internal (in /bin/bash) >> ==18051== by 0x43851D: execute_command (in /bin/bash) >> ==18051== by 0x42139D: reader_loop (in /bin/bash) >> ==18051== by 0x41FDB0: main (in /bin/bash) >> ==18051== Address 0x4240708 is in the brk data segment 0x4228000-0x4246fff >> ==18051=>> > > Not at all clear to me what to make of this. Does it indicate problems > or memory leaks in my installation of R? Anyhow, things then proceed in > an expected manner: > >> R version 3.5.1 (2018-07-02) -- "Feather Spray" >> Copyright (C) 2018 The R Foundation for Statistical Computing >> Platform: x86_64-pc-linux-gnu (64-bit) >> >> R is free software and comes with ABSOLUTELY NO WARRANTY. >> You are welcome to redistribute it under certain conditions. >> Type 'license()' or 'licence()' for distribution details. >> >> Natural language support but running in an English locale >> >> R is a collaborative project with many contributors. >> Type 'contributors()' for more information and >> 'citation()' on how to cite R or R packages in publications. >> >> Type 'demo()' for some demos, 'help()' for on-line help, or >> 'help.start()' for an HTML browser interface to help. >> Type 'q()' to quit R. >> >> Loading required package: misc >> [Previously saved workspace restored] > > I then loaded the problematic package and issued the problematic command: > >>> library(hmm.discnp) >> hmm.discnp 2.0-9 >> >> This package has changed SUBSTANTIALLY from its >> previous release. Read the documentation >> carefully. Note in particular that the meaning of >> the argument "nsim" of the function rhmm() has >> changed, and a new argument "ylengths" now plays >> essentially the role previously played by >> "nsim". >> >>> xxx <- get.hgl(p3,2,yyy) >> >> *** caught segfault *** >> address (nil), cause 'unknown' >> Segmentation fault (core dumped) > > Nothing informative. Is there something else I should be doing? > > Sorry for being a nuisance, but I am at a loss. > > cheers, > > Rolf >