[R] Mysterious seg fault.

[Rolf Turner]

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

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