Mysterious seg fault.

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Mysterious seg fault.

Rolf Turner

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

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault.

Göran Broström-3
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
>

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault.

plangfelder
In reply to this post by 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 <[hidden email]> 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
>
> ______________________________________________
> [hidden email] 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]]

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault.

Eric Berger
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 <
[hidden email]> 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 <[hidden email]>
> 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
> >
> > ______________________________________________
> > [hidden email] 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]]
>
> ______________________________________________
> [hidden email] 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]]

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault.

Rolf Turner
In reply to this post by Göran Broström-3
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

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault.

Rolf Turner
In reply to this post by Eric Berger

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

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault.

Duncan Murdoch-2
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
>

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault.

Rolf Turner
On 13/08/18 12:03, Duncan Murdoch wrote:

<SNIP>

>> 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.

<SNIP>

Thanks Duncan.  I did as you said with valgrind and got output that is
probably more relevant.  However it is still opaque to me.  I have no
idea how to use it to track down the error that I am making in the code.

> xxx <- get.hgl(p3,2,yyy)
> ==20088== Invalid read of size 8
> ==20088==    at 0x5116CD: Rf_allocVector3 (memory.c:2539)
> ==20088==    by 0x4B40FF: Rf_allocVector (Rinlinedfuns.h:577)
> ==20088==    by 0x4B40FF: do_missing (envir.c:2265)
> ==20088==    by 0x4CA383: bcEval (eval.c:6801)
> ==20088==    by 0x4D99EF: Rf_eval (eval.c:624)
> ==20088==    by 0x4DB172: R_execClosure (eval.c:1773)
> ==20088==    by 0x4D0E6E: bcEval (eval.c:6749)
> ==20088==    by 0x4D99EF: Rf_eval (eval.c:624)
> ==20088==    by 0x4DB172: R_execClosure (eval.c:1773)
> ==20088==    by 0x4D0E6E: bcEval (eval.c:6749)
> ==20088==    by 0x4D99EF: Rf_eval (eval.c:624)
> ==20088==    by 0x4DB172: R_execClosure (eval.c:1773)
> ==20088==    by 0x4D99A1: Rf_eval (eval.c:747)
> ==20088==  Address 0x3fca86ccfb7de9cc is not stack'd, malloc'd or (recently) free'd
> ==20088==
>
>  *** caught segfault ***
> address (nil), cause 'unknown'
> ==20088== Invalid read of size 8
> ==20088==    at 0x511B23: Rf_allocVector3 (memory.c:2691)
> ==20088==    by 0x49137A: Rf_allocVector (Rinlinedfuns.h:577)
> ==20088==    by 0x49137A: deparse1WithCutoff (deparse.c:268)
> ==20088==    by 0x492EAF: Rf_deparse1m (deparse.c:197)
> ==20088==    by 0x4BA99C: R_GetTraceback (errors.c:1409)
> ==20088==    by 0x5053CE: sigactionSegv (main.c:592)
> ==20088==    by 0x6CA738F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so)
> ==20088==    by 0x5116CC: Rf_allocVector3 (memory.c:2539)
> ==20088==  Address 0x3fca86ccfb7de9cc is not stack'd, malloc'd or (recently) free'd
> ==20088==
> ==20088==
> ==20088== Process terminating with default action of signal 11 (SIGSEGV)
> ==20088==  General Protection Fault
> ==20088==    at 0x511B23: Rf_allocVector3 (memory.c:2691)
> ==20088==    by 0x49137A: Rf_allocVector (Rinlinedfuns.h:577)
> ==20088==    by 0x49137A: deparse1WithCutoff (deparse.c:268)
> ==20088==    by 0x492EAF: Rf_deparse1m (deparse.c:197)
> ==20088==    by 0x4BA99C: R_GetTraceback (errors.c:1409)
> ==20088==    by 0x5053CE: sigactionSegv (main.c:592)
> ==20088==    by 0x6CA738F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so)
> ==20088==    by 0x5116CC: Rf_allocVector3 (memory.c:2539)
> ==20088==
> ==20088== HEAP SUMMARY:
> ==20088==     in use at exit: 210,111,063 bytes in 57,981 blocks
> ==20088==   total heap usage: 106,693 allocs, 48,712 frees, 349,208,345 bytes allocated
> ==20088==
> ==20088== LEAK SUMMARY:
> ==20088==    definitely lost: 0 bytes in 0 blocks
> ==20088==    indirectly lost: 0 bytes in 0 blocks
> ==20088==      possibly lost: 0 bytes in 0 blocks
> ==20088==    still reachable: 210,111,063 bytes in 57,981 blocks
> ==20088==                       of which reachable via heuristic:
> ==20088==                         newarray           : 4,264 bytes in 1 blocks
> ==20088==         suppressed: 0 bytes in 0 blocks
> ==20088== Rerun with --leak-check=full to see details of leaked memory
> ==20088==
> ==20088== For counts of detected and suppressed errors, rerun with: -v
> ==20088== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
> Segmentation fault (core dumped)

Doesn't mean a thing to me, I'm afraid.  Does it mean anything to you?
I have not (yet) "rerun with: -v".  I suspect that this would not help.

I guess I'll try to get gdb going next, and see if that provides more
lucid output.

cheers,

Rolf

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

Rolf Turner
In reply to this post by Duncan Murdoch-2

OK everybody!  You can relax.  :-) I managed to spot the loony.  After
mucking around with valgrind, and before trying gdb, I had one more look
at my code and *finally* saw the stupid thing that I had been doing.

In the call to .Fortran() I had a line

     nphi=as.integer(nphi),

but "nphi" was nowhere defined (!!!) in the R code.  The name "nphi"
appeared as an argument in the Fortran subroutine in question, but was
nowhere actually *used*!!!

It seems that passing a non-existent value as an argument to a Fortran
subroutine can *sometimes* confuse it.  Understandably.

I think that this "nphi" was a left-over from an earlier version of the
code.  I must have changed the code so that nphi was no longer needed,
but then forgot to remove it from some places.  Psigh!  I hate myself
sometimes.

Anyhow, thanks to all those who took the time and made the effort to try
to help me.

cheers,

Rolf

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

Henrik Bengtsson-5
On Mon, Aug 13, 2018 at 3:51 AM Rolf Turner <[hidden email]> wrote:

>
>
> OK everybody!  You can relax.  :-) I managed to spot the loony.  After
> mucking around with valgrind, and before trying gdb, I had one more look
> at my code and *finally* saw the stupid thing that I had been doing.
>
> In the call to .Fortran() I had a line
>
>      nphi=as.integer(nphi),
>
> but "nphi" was nowhere defined (!!!) in the R code.  The name "nphi"
> appeared as an argument in the Fortran subroutine in question, but was
> nowhere actually *used*!!!

Didn't R CMD check pick this up, that is, didn't it report that 'nphi'
is a "global" variable?

/Henrik

>
> It seems that passing a non-existent value as an argument to a Fortran
> subroutine can *sometimes* confuse it.  Understandably.
>
> I think that this "nphi" was a left-over from an earlier version of the
> code.  I must have changed the code so that nphi was no longer needed,
> but then forgot to remove it from some places.  Psigh!  I hate myself
> sometimes.
>
> Anyhow, thanks to all those who took the time and made the effort to try
> to help me.
>
> cheers,
>
> Rolf
>
> --
> Technical Editor ANZJS
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
> ______________________________________________
> [hidden email] 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.

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

Rolf Turner

On 13/08/18 20:45, Henrik Bengtsson wrote:

> On Mon, Aug 13, 2018 at 3:51 AM Rolf Turner <[hidden email]> wrote:
>>
>>
>> OK everybody!  You can relax.  :-) I managed to spot the loony.  After
>> mucking around with valgrind, and before trying gdb, I had one more look
>> at my code and *finally* saw the stupid thing that I had been doing.
>>
>> In the call to .Fortran() I had a line
>>
>>       nphi=as.integer(nphi),
>>
>> but "nphi" was nowhere defined (!!!) in the R code.  The name "nphi"
>> appeared as an argument in the Fortran subroutine in question, but was
>> nowhere actually *used*!!!
>
> Didn't R CMD check pick this up, that is, didn't it report that 'nphi'
> is a "global" variable?

No it didn't.  The name only appears in the call to .Fortran().  I think
if it appeared in a call to an ordinary garden-variety R function then a
warning would have been issued.

Such a lapse would be hard for R CMD check to pick up.  E.g

    nphi=integer(1),

would be OK in a call to .Fortran (which would allow a value of nphi,
calculated within the called subroutine, to be *returned*) whereas

    nphi=as.integer(nphi),

causes trouble when nphi has never been defined (as I found out after a
great expenditure of time and torn-out hair).  In the former instance it
doesn't matter an FTCF whether nphi has been defined or not.

cheers,

Rolf

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

Peter Dalgaard-2
It's odd, possibly a bug, that you don't get

Error: object 'nphi' not found

but I can't offhand see where the evaluation of args to .C/.Fortran is supposed to take place.

-pd

> On 13 Aug 2018, at 11:54 , Rolf Turner <[hidden email]> wrote:
>
>
> On 13/08/18 20:45, Henrik Bengtsson wrote:
>
>> On Mon, Aug 13, 2018 at 3:51 AM Rolf Turner <[hidden email]> wrote:
>>>
>>>
>>> OK everybody!  You can relax.  :-) I managed to spot the loony.  After
>>> mucking around with valgrind, and before trying gdb, I had one more look
>>> at my code and *finally* saw the stupid thing that I had been doing.
>>>
>>> In the call to .Fortran() I had a line
>>>
>>>      nphi=as.integer(nphi),
>>>
>>> but "nphi" was nowhere defined (!!!) in the R code.  The name "nphi"
>>> appeared as an argument in the Fortran subroutine in question, but was
>>> nowhere actually *used*!!!
>> Didn't R CMD check pick this up, that is, didn't it report that 'nphi'
>> is a "global" variable?
>
> No it didn't.  The name only appears in the call to .Fortran().  I think if it appeared in a call to an ordinary garden-variety R function then a warning would have been issued.
>
> Such a lapse would be hard for R CMD check to pick up.  E.g
>
>   nphi=integer(1),
>
> would be OK in a call to .Fortran (which would allow a value of nphi, calculated within the called subroutine, to be *returned*) whereas
>
>   nphi=as.integer(nphi),
>
> causes trouble when nphi has never been defined (as I found out after a great expenditure of time and torn-out hair).  In the former instance it doesn't matter an FTCF whether nphi has been defined or not.
>
> cheers,
>
> Rolf
>
> --
> Technical Editor ANZJS
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
> ______________________________________________
> [hidden email] 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.

--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

Rolf Turner
On 13/08/18 23:39, peter dalgaard wrote:
> It's odd, possibly a bug, that you don't get
>
> Error: object 'nphi' not found
>
> but I can't offhand see where the evaluation of args to .C/.Fortran is supposed to take place.

If it is indeed a bug then it would be nice an it were fixed.  If that
is possible.  Way beyond my level of comprehension but.

cheers,

Rolf

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

Peter Dalgaard-2
Hmm,

> .Fortran(stats:::C_setsmu, as.integer(0))
[[1]]
[1] 0

> .Fortran(stats:::C_setsmu, as.integer(fumble))
Error: object 'fumble' not found
> .Fortran(stats:::C_setsmu, fumble=as.integer(fumble))
Error: object 'fumble' not found
> .Fortran(stats:::C_setsmu, nphi=as.integer(nphi))
Error: object 'nphi' not found

so I think we need an alternative hypothesis about what went wrong for you...

If nphi was NULL from the outset, that could explain things.

-pd


> On 14 Aug 2018, at 01:16 , Rolf Turner <[hidden email]> wrote:
>
> On 13/08/18 23:39, peter dalgaard wrote:
>> It's odd, possibly a bug, that you don't get
>> Error: object 'nphi' not found
>> but I can't offhand see where the evaluation of args to .C/.Fortran is supposed to take place.
>
> If it is indeed a bug then it would be nice an it were fixed.  If that is possible.  Way beyond my level of comprehension but.
>
> cheers,
>
> Rolf
>
> --
> Technical Editor ANZJS
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276

--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

Rolf Turner
On 14/08/18 23:01, peter dalgaard wrote:

> Hmm,
>
>> .Fortran(stats:::C_setsmu, as.integer(0))
> [[1]]
> [1] 0
>
>> .Fortran(stats:::C_setsmu, as.integer(fumble))
> Error: object 'fumble' not found
>> .Fortran(stats:::C_setsmu, fumble=as.integer(fumble))
> Error: object 'fumble' not found
>> .Fortran(stats:::C_setsmu, nphi=as.integer(nphi))
> Error: object 'nphi' not found
>
> so I think we need an alternative hypothesis about what went wrong for you...
>
> If nphi was NULL from the outset, that could explain things.

No, I never set nphi to NULL.

I put the code back to the way it was previously, just now, and tried
again. Now I get "object 'nphi' not found".

There is no explanation other than gremlins and the malevolence that the
computer gods hold towards me.

cheers,

Rolf

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

Richard M. Heiberger
There is no explanation other than gremlins and the malevolence that
the computer gods hold towards me.

fortune nomination.

On Tue, Aug 14, 2018 at 7:12 PM, Rolf Turner <[hidden email]> wrote:

> On 14/08/18 23:01, peter dalgaard wrote:
>>
>> Hmm,
>>
>>> .Fortran(stats:::C_setsmu, as.integer(0))
>>
>> [[1]]
>> [1] 0
>>
>>> .Fortran(stats:::C_setsmu, as.integer(fumble))
>>
>> Error: object 'fumble' not found
>>>
>>> .Fortran(stats:::C_setsmu, fumble=as.integer(fumble))
>>
>> Error: object 'fumble' not found
>>>
>>> .Fortran(stats:::C_setsmu, nphi=as.integer(nphi))
>>
>> Error: object 'nphi' not found
>>
>> so I think we need an alternative hypothesis about what went wrong for
>> you...
>>
>> If nphi was NULL from the outset, that could explain things.
>
>
> No, I never set nphi to NULL.
>
> I put the code back to the way it was previously, just now, and tried again.
> Now I get "object 'nphi' not found".
>
> There is no explanation other than gremlins and the malevolence that the
> computer gods hold towards me.
>
> cheers,
>
> Rolf
>
> --
> Technical Editor ANZJS
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
> ______________________________________________
> [hidden email] 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.

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

Rolf Turner
On 15/08/18 13:00, Richard M. Heiberger wrote:
> There is no explanation other than gremlins and the malevolence that
> the computer gods hold towards me.
>
> fortune nomination.

I demur.  I already have a fortune with gremlins in it attributed to me
(fortune(213)).

cheers,

Rolf

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Mysterious seg fault --- SOLVED

chrishold
Ah, if I'd had a fortune for every time I invoked the wrath of the IT gods and the malicious work of their gremlins, I'd be an obscenely wealthy person by now.

More seriously, I can't tell you how much I appreciate the joyous flickers of humour here, amidst all the pain and suffering (yes, I may be projecting a bit here), and the welcome, vital, but often humiliating genius many contributors bring as it underlines how low my statistical and computing IQ is.

I have Rolf as #1 for self-deprecating humour on r-help.  Keep rescuing my sense of humour on my gremlin-beset days please Rolf, all!

Chris

----- Original Message -----
> From: "Rolf Turner" <[hidden email]>
> To: "Richard M. Heiberger" <[hidden email]>
> Cc: [hidden email], "Achim Zeileis" <[hidden email]>, "peter dalgaard" <[hidden email]>, "Henrik
> Bengtsson" <[hidden email]>
> Sent: Wednesday, 15 August, 2018 04:58:32
> Subject: Re: [R] Mysterious seg fault --- SOLVED

> On 15/08/18 13:00, Richard M. Heiberger wrote:
>> There is no explanation other than gremlins and the malevolence that
>> the computer gods hold towards me.
>>
>> fortune nomination.
>
> I demur.  I already have a fortune with gremlins in it attributed to me
> (fortune(213)).
>
> cheers,
>
> Rolf
>
> --
> Technical Editor ANZJS
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
> ______________________________________________
> [hidden email] 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.

______________________________________________
[hidden email] 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.