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&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 > > cl...@duke.edu<mailto:cl...@duke.edu> > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-package-devel@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....@cbs.dk Priv: pda...@gmail.com [[alternative HTML version deleted]]
______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
