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 R
I 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
______________________________________________
R-help@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.
