I don't think I can offer anything beyond the Valgrind FAQ at this point. I kind of suspect that the other trace -- pointing to where the offending piece of memory was allocated --would provide the better clue about the source of the problem.
-pd > On 25 May 2017, at 04:47 , Merlise Clyde, Ph.D. <cl...@duke.edu> wrote: > > 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 > 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 -- 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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
