Re: [R-pkg-devel] Help package checks using valgrind

2017-05-24 Thread Merlise Clyde, Ph.D. 
Thanks - I missed that one!   After identifying the problem there, and 
increasing --num-callers in  my .valgrindrc file I can see more of the trace, 
however, I still have short entries like

> cleanEx()
==2044952== Conditional jump or move depends on uninitialised value(s)
==2044952==at 0x405A0CB: ???
==2044952==by 0x189D0A5F: ???
==2044952==by 0x189D0A5F: ???
==2044952==by 0x189D0A7B: ???
==2044952==by 0xFFEFED09F: ???
==2044952==
detaching  package:MASS

Any suggestions on how to get more details on what is occurring at that point?

Thanks!
Merlise

From: peter dalgaard <pda...@gmail.com>
Sent: Tuesday, May 23, 2017 6:40 PM
To: Merlise Clyde, Ph.D.
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Help package checks using valgrind


> On 23 May 2017, at 23:40 , Merlise Clyde, Ph.D. <cl...@duke.edu> wrote:
>
> I am trying to resolve the Additional Issues reported by CRAN @ 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.stats.ox.ac.uk_pub_bdr_memtests_valgrind_BAS-2DEx.Rout=DwIFaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=NOkxkvdFOOffXzeTY2kgZQ=NwjTuJcFlu_aiLanr5CmvC1iVoHoWRZ7GZRFeq3WOBE=58920PEhsbU1YFCH1hHuLt2t9FcOYIAvfZq_swf1lLc=
>   for my package BAS which calls C and Fortran.
>
> The output from the above URL is not particularly informative (at least to 
> me) for identifying where the problems are in the source code, as there are  
> missing file names and line numbers as seen in this snippet from the above 
> url:
>

The first of those traces does actually point to something that should be 
useful to you:

> cleanEx()
==9861== Conditional jump or move depends on uninitialised value(s)
==9861==at 0x403DBF3: ???
==9861==by 0x1702DE57: ???
==9861==by 0x1702DE57: ???
==9861==by 0x1702DE73: ???
==9861==by 0xFFEFF861F: ???
==9861==  Uninitialised value was created by a heap allocation
==9861==at 0x4C2BBAD: malloc 
(/builddir/build/BUILD/valgrind-3.11.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299)
==9861==by 0x4E5AFE: GetNewPage (svn/R-devel/src/main/memory.c:875)
==9861==by 0x4E77AF: Rf_allocVector3 (svn/R-devel/src/main/memory.c:2651)
==9861==by 0x14B29729: sampleworep 
(packages/tests-vg/BAS/src/sampleworep.c:395)
==9861==by 0x47C36D: R_doDotCall (svn/R-devel/src/main/dotcode.c:617)

i.e. you are allocating something at sampleworep.c:395 but it isn't initialized 
before something somewhere uses its value to make a decision. So possibly you 
should initialize the vector immediately after allocation.

In the other cases, you seem to be too deep in R internals to let you see the 
origin in your package, i.e., your stack traces are too short. According to the 
Valgrind FAQ, you can use --num-callers to make them longer. Figuring out how 
to pass that to valgrind as invoked by R is, um, left as an exercise for the 
reader.

-pd

>
>> cleanEx()
> ==9861== Conditional jump or move depends on uninitialised value(s)
> ==9861==at 0x403DBF3: ???
> ==9861==by 0x1A694397: ???
> ==9861==by 0x1A694397: ???
> ==9861==by 0x1A6943B3: ???
> ==9861==by 0xFFEFF861F: ???
> ==9861==  Uninitialised value was created by a heap allocation
> ==9861==at 0x4C2BBAD: malloc 
> (/builddir/build/BUILD/valgrind-3.11.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299)
> ==9861==by 0x4E5AFE: GetNewPage (svn/R-devel/src/main/memory.c:875)
> ==9861==by 0x4E77AF: Rf_allocVector3 (svn/R-devel/src/main/memory.c:2651)
> ==9861==by 0x4E79A8: Rf_allocVector 
> (svn/R-devel/src/include/Rinlinedfuns.h:196)
> ==9861==by 0x4E79A8: R_alloc (svn/R-devel/src/main/memory.c:2160)
> ==9861==by 0x540C52: logicalSubscript 
> (svn/R-devel/src/main/subscript.c:563)
> ==9861==by 0x5437BE: realSubscript (svn/R-devel/src/main/subscript.c:723)
> ==9861==by 0x5437BE: Rf_makeSubscript 
> (svn/R-devel/src/main/subscript.c:980)
> ==9861==by 0x5455AB: VectorSubset (svn/R-devel/src/main/subset.c:188)
> ==9861==by 0x5455AB: do_subset_dflt (svn/R-devel/src/main/subset.c:826)
> ==9861==by 0x4A8539: VECSUBSET_PTR (svn/R-devel/src/main/eval.c:5179)
> ==9861==by 0x4A8539: bcEval (svn/R-devel/src/main/eval.c:6618)
> ==9861==by 0x4B685F: Rf_eval (svn/R-devel/src/main/eval.c:624)
> ==9861==by 0x4B894E: R_execClosure (svn/R-devel/src/main/eval.c:1614)
> ==9861==by 0x4EA827: dispatchMethod (svn/R-devel/src/main/objects.c:335)
> ==9861==by 0x4EAC12: Rf_usemethod (svn/R-devel/src/main/objects.c:375)
> ==9861==
>
>
>
> To see if I could replicate locally and debug, I have built R 3.4.0 with 
> valgrind-3.11.0 on FC 23  using the configuration options
>
> ./configure --with-valgrind-instrumentation=2 
> --with-system-valgrind-headers=yes CFLAGS='-g -O0' FCFLAGS='-g -O0�
>
> My package is built also u

Re: [R-pkg-devel] Help package checks using valgrind

2017-05-23 Thread peter dalgaard 

> On 23 May 2017, at 23:40 , Merlise Clyde, Ph.D.  wrote:
> 
> I am trying to resolve the Additional Issues reported by CRAN @ 
> https://www.stats.ox.ac.uk/pub/bdr/memtests/valgrind/BAS-Ex.Rout for my 
> package BAS which calls C and Fortran.
> 
> The output from the above URL is not particularly informative (at least to 
> me) for identifying where the problems are in the source code, as there are  
> missing file names and line numbers as seen in this snippet from the above 
> url:
> 

The first of those traces does actually point to something that should be 
useful to you:

> cleanEx()
==9861== Conditional jump or move depends on uninitialised value(s)
==9861==at 0x403DBF3: ???
==9861==by 0x1702DE57: ???
==9861==by 0x1702DE57: ???
==9861==by 0x1702DE73: ???
==9861==by 0xFFEFF861F: ???
==9861==  Uninitialised value was created by a heap allocation
==9861==at 0x4C2BBAD: malloc 
(/builddir/build/BUILD/valgrind-3.11.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299)
==9861==by 0x4E5AFE: GetNewPage (svn/R-devel/src/main/memory.c:875)
==9861==by 0x4E77AF: Rf_allocVector3 (svn/R-devel/src/main/memory.c:2651)
==9861==by 0x14B29729: sampleworep 
(packages/tests-vg/BAS/src/sampleworep.c:395)
==9861==by 0x47C36D: R_doDotCall (svn/R-devel/src/main/dotcode.c:617)

i.e. you are allocating something at sampleworep.c:395 but it isn't initialized 
before something somewhere uses its value to make a decision. So possibly you 
should initialize the vector immediately after allocation.

In the other cases, you seem to be too deep in R internals to let you see the 
origin in your package, i.e., your stack traces are too short. According to the 
Valgrind FAQ, you can use --num-callers to make them longer. Figuring out how 
to pass that to valgrind as invoked by R is, um, left as an exercise for the 
reader.

-pd

> 
>> cleanEx()
> ==9861== Conditional jump or move depends on uninitialised value(s)
> ==9861==at 0x403DBF3: ???
> ==9861==by 0x1A694397: ???
> ==9861==by 0x1A694397: ???
> ==9861==by 0x1A6943B3: ???
> ==9861==by 0xFFEFF861F: ???
> ==9861==  Uninitialised value was created by a heap allocation
> ==9861==at 0x4C2BBAD: malloc 
> (/builddir/build/BUILD/valgrind-3.11.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299)
> ==9861==by 0x4E5AFE: GetNewPage (svn/R-devel/src/main/memory.c:875)
> ==9861==by 0x4E77AF: Rf_allocVector3 (svn/R-devel/src/main/memory.c:2651)
> ==9861==by 0x4E79A8: Rf_allocVector 
> (svn/R-devel/src/include/Rinlinedfuns.h:196)
> ==9861==by 0x4E79A8: R_alloc (svn/R-devel/src/main/memory.c:2160)
> ==9861==by 0x540C52: logicalSubscript 
> (svn/R-devel/src/main/subscript.c:563)
> ==9861==by 0x5437BE: realSubscript (svn/R-devel/src/main/subscript.c:723)
> ==9861==by 0x5437BE: Rf_makeSubscript 
> (svn/R-devel/src/main/subscript.c:980)
> ==9861==by 0x5455AB: VectorSubset (svn/R-devel/src/main/subset.c:188)
> ==9861==by 0x5455AB: do_subset_dflt (svn/R-devel/src/main/subset.c:826)
> ==9861==by 0x4A8539: VECSUBSET_PTR (svn/R-devel/src/main/eval.c:5179)
> ==9861==by 0x4A8539: bcEval (svn/R-devel/src/main/eval.c:6618)
> ==9861==by 0x4B685F: Rf_eval (svn/R-devel/src/main/eval.c:624)
> ==9861==by 0x4B894E: R_execClosure (svn/R-devel/src/main/eval.c:1614)
> ==9861==by 0x4EA827: dispatchMethod (svn/R-devel/src/main/objects.c:335)
> ==9861==by 0x4EAC12: Rf_usemethod (svn/R-devel/src/main/objects.c:375)
> ==9861==
> 
> 
> 
> To see if I could replicate locally and debug, I have built R 3.4.0 with 
> valgrind-3.11.0 on FC 23  using the configuration options
> 
> ./configure --with-valgrind-instrumentation=2 
> --with-system-valgrind-headers=yes CFLAGS='-g -O0' FCFLAGS='-g -O0’
> 
> My package is built also using -g and -O0 for debugging and turning off 
> optimization.
> 
> Running  valgrind on the output from examples/vignettes from R CMD check
> 
> R -d "valgrind --tool=memcheck --leak-check=full --track-origins=yes" 
> --vanilla < BAS.Rcheck/BAS-Ex.R
> 
> produces similar output as from CRAN -  i.e. no line numbers to code  (I have 
> also tried travis-CI which indicates no problems and  R-devel under docker  
> which also replicates the non informative messages of CRAN :-)  so clearly 
> missing something to produce the line numbers.
> 
> Questions:
> 
> 
> 1) Are these problems with libraries outside of my code  or fortran  and I 
> can ask CRAN to ignore? How can I tell if these are problems with system 
> libraries (i.e. configuration on my system, but also those for CRAN) rather 
> than my package code?
> 
> 2) Any suggestions for other configuration options (system, R, package. 
> valgrind) that would provide more informative output?
>(for Fedora or any other platforms using docker)
> 
> 3) Any alternative methods recommended for tracking this down instead of 
> using valgrind?
> 
> 
> 
> Thanks!
> Merlise
> 
>> sessionInfo()
> R version 3.4.0 (2017-04-21)
>

[R-pkg-devel] Help package checks using valgrind

2017-05-23 Thread Merlise Clyde, Ph.D. 
I am trying to resolve the Additional Issues reported by CRAN @ 
https://www.stats.ox.ac.uk/pub/bdr/memtests/valgrind/BAS-Ex.Rout for my package 
BAS which calls C and Fortran.

The output from the above URL is not particularly informative (at least to me) 
for identifying where the problems are in the source code, as there are  
missing file names and line numbers as seen in this snippet from the above url:


> cleanEx()
==9861== Conditional jump or move depends on uninitialised value(s)
==9861==at 0x403DBF3: ???
==9861==by 0x1A694397: ???
==9861==by 0x1A694397: ???
==9861==by 0x1A6943B3: ???
==9861==by 0xFFEFF861F: ???
==9861==  Uninitialised value was created by a heap allocation
==9861==at 0x4C2BBAD: malloc 
(/builddir/build/BUILD/valgrind-3.11.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299)
==9861==by 0x4E5AFE: GetNewPage (svn/R-devel/src/main/memory.c:875)
==9861==by 0x4E77AF: Rf_allocVector3 (svn/R-devel/src/main/memory.c:2651)
==9861==by 0x4E79A8: Rf_allocVector 
(svn/R-devel/src/include/Rinlinedfuns.h:196)
==9861==by 0x4E79A8: R_alloc (svn/R-devel/src/main/memory.c:2160)
==9861==by 0x540C52: logicalSubscript (svn/R-devel/src/main/subscript.c:563)
==9861==by 0x5437BE: realSubscript (svn/R-devel/src/main/subscript.c:723)
==9861==by 0x5437BE: Rf_makeSubscript (svn/R-devel/src/main/subscript.c:980)
==9861==by 0x5455AB: VectorSubset (svn/R-devel/src/main/subset.c:188)
==9861==by 0x5455AB: do_subset_dflt (svn/R-devel/src/main/subset.c:826)
==9861==by 0x4A8539: VECSUBSET_PTR (svn/R-devel/src/main/eval.c:5179)
==9861==by 0x4A8539: bcEval (svn/R-devel/src/main/eval.c:6618)
==9861==by 0x4B685F: Rf_eval (svn/R-devel/src/main/eval.c:624)
==9861==by 0x4B894E: R_execClosure (svn/R-devel/src/main/eval.c:1614)
==9861==by 0x4EA827: dispatchMethod (svn/R-devel/src/main/objects.c:335)
==9861==by 0x4EAC12: Rf_usemethod (svn/R-devel/src/main/objects.c:375)
==9861==



To see if I could replicate locally and debug, I have built R 3.4.0 with 
valgrind-3.11.0 on FC 23  using the configuration options

./configure --with-valgrind-instrumentation=2 
--with-system-valgrind-headers=yes CFLAGS='-g -O0' FCFLAGS='-g -O0’

My package is built also using -g and -O0 for debugging and turning off 
optimization.

Running  valgrind on the output from examples/vignettes from R CMD check

R -d "valgrind --tool=memcheck --leak-check=full --track-origins=yes" --vanilla 
< BAS.Rcheck/BAS-Ex.R

produces similar output as from CRAN -  i.e. no line numbers to code  (I have 
also tried travis-CI which indicates no problems and  R-devel under docker  
which also replicates the non informative messages of CRAN :-)  so clearly 
missing something to produce the line numbers.

Questions:


1) Are these problems with libraries outside of my code  or fortran  and I can 
ask CRAN to ignore? How can I tell if these are problems with system libraries 
(i.e. configuration on my system, but also those for CRAN) rather than my 
package code?

2) Any suggestions for other configuration options (system, R, package. 
valgrind) that would provide more informative output?
(for Fedora or any other platforms using docker)

3) Any alternative methods recommended for tracking this down instead of using 
valgrind?



Thanks!
Merlise

> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Fedora 23 (Twenty Three)

Matrix products: default
BLAS: /usr/local/lib64/R/lib/libRblas.so
LAPACK: /usr/local/lib64/R/lib/libRlapack.so


source code is at http://github.com/merliseclyde/BAS



Merlise A Clyde
Professor & Chair Department of Statistical Science
Duke University
http://stat.duke.edu/~clyde

cl...@duke.edu



[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel