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

Merlise Clyde, Ph.D. clyde at duke.edu
Thu May 25 04:47:36 CEST 2017


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 <pdalgd at gmail.com>
Sent: Tuesday, May 23, 2017 6:40 PM
To: Merlise Clyde, Ph.D.
Cc: r-package-devel at r-project.org
Subject: Re: [R-pkg-devel] Help package checks using valgrind


> On 23 May 2017, at 23:40 , Merlise Clyde, Ph.D. <clyde at 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&d=DwIFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=NOkxkvdFOOffXzeTY2kgZQ&m=NwjTuJcFlu_aiLanr5CmvC1iVoHoWRZ7GZRFeq3WOBE&s=58920PEhsbU1YFCH1hHuLt2t9FcOYIAvfZq_swf1lLc&e=  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)
> 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_merliseclyde_BAS&d=DwIFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=NOkxkvdFOOffXzeTY2kgZQ&m=NwjTuJcFlu_aiLanr5CmvC1iVoHoWRZ7GZRFeq3WOBE&s=eu-Lj1is3biRf2EIcGlpuDf70-EXNpxfSjEA4XRdG7A&e=
>
>
>
> Merlise A Clyde
> Professor & Chair Department of Statistical Science
> Duke University
> http://stat.duke.edu/~clyde
Merlise A Clyde<http://stat.duke.edu/~clyde>
stat.duke.edu
Merlise Clyde is Professor of Statistical Science and Chair of the Department



>
> clyde at duke.edu<mailto:clyde at duke.edu>
>
>
>
>        [[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dpackage-2Ddevel&d=DwIFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=NOkxkvdFOOffXzeTY2kgZQ&m=NwjTuJcFlu_aiLanr5CmvC1iVoHoWRZ7GZRFeq3WOBE&s=gI000alCIBMmXI3JSu5ixDfuYaMmD8Hm4PAO0h8Yf3Y&e=

--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com










	[[alternative HTML version deleted]]



More information about the R-package-devel mailing list