Re: [Rd] uninitialised value in R (PR#13476)
Hi Mathieu,
Very strange.
(i) The whole package RandomFields is written with ` extern "C" '
and seems working. There is no message from valgrind
anywhere, except in two situations that I have boiled
down to the code in the bug report.
(ii) without ` extern "C" ' I get a warning plus an
error:
> .Call("XXX")
==18032== Conditional jump or move depends on uninitialised value(s)
==18032==at 0x401620C: (within /lib/ld-2.8.so)
==18032==by 0x42825C3: (within /lib/libc-2.8.so)
==18032==by 0x4282989: _dl_sym (in /lib/libc-2.8.so)
==18032==by 0x417ADE7: (within /lib/libdl-2.8.so)
==18032==by 0x400DE25: (within /lib/ld-2.8.so)
==18032==by 0x417B0DB: (within /lib/libdl-2.8.so)
==18032==by 0x417AD72: dlsym (in /lib/libdl-2.8.so)
==18032==by 0x811012D: R_dlsym (Rdynload.c:787)
==18032==by 0x8110A98: R_FindSymbol (Rdynload.c:836)
==18032==by 0x816E41C: resolveNativeRoutine (dotcode.c:240)
==18032==by 0x817473A: do_dotcall (dotcode.c:825)
==18032==by 0x8194C12: Rf_eval (eval.c:487)
==18032==by 0x805B163: Rf_ReplIteration (main.c:257)
==18032==by 0x805B3E7: R_ReplConsole (main.c:306)
==18032==by 0x805B6D7: run_Rmainloop (main.c:966)
==18032==by 0x8058F80: main (Rmain.c:33)
Error in .Call("XXX") : C symbol name "XXX" not in load table
Have you named the file u.c or u.cc?
Cheers,
Martin
Mathieu Ribatet wrote:
> Hi Martin,
>
> I wasn't able to compile your files. Replacing "extern "C" SEXP XXX();"
> by "SEXP XXX();" solve the issue and I got no message from valgrind -
> I'm not sure this is what you really want to do though.
> I hope this might help.
> Cheers,
> Mathieu
>
>
> schlat...@math.uni-goettingen.de a écrit :
>> Hi,
>>
>> I get an "Conditional jump or move depends on uninitialised value(s)"
>> from valgrind when using 'solve' in combination with some simple
>> C-code. (I did not use other functions of R besides 'solve'.)
>>
>> In detail: running
>>
>> R --vanilla -d "valgrind --tool=memcheck --memcheck:leak-check=yes
>> --num-callers=20 "
>>
>> and calling
>>
>> .Call("XXX")
>> nd <- 3
>> solve(diag(nd) , as.vector(1:nd))
>> .Call("XXX")
>>
>> gives the above valgrind message for the second call of "XXX".
>> Without "solve" in the middle, there is no message
>> from valgrind.
>>
>> Best regards,
>> Martin
>>
>>
>> /// C source file u.cc
>> #include "u.h"
>>
>> SEXP XXX() {
>> SEXP ans;
>> PROTECT (ans = allocVector(INTSXP, 1));
>> INTEGER(ans)[0] = 1;
>> UNPROTECT(1);
>> return ans;
>> }
>>
>>
>> /// header file u.h
>> #ifndef RFsimu_public_H
>> #define RFsimu_public_H 1
>>
>> #include
>> #include
>> #include
>> #include
>>
>> extern "C" SEXP XXX();
>>
>>
>> #endif /* RF_simu_PUBLIC_H*/
>>
>>
>>
>>
>>
>>
>> --please do not edit the information below--
>>
>> Version:
>> platform = i686-pc-linux-gnu
>> arch = i686
>> os = linux-gnu
>> system = i686, linux-gnu
>> status = Under development (unstable)
>> major = 2
>> minor = 9.0
>> year = 2009
>> month = 01
>> day = 13
>> svn rev = 47573
>> language = R
>> version.string = R version 2.9.0 Under development (unstable)
>> (2009-01-13 r47573)
>>
>> Locale:
>> LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
>>
>>
>> Search Path:
>> .GlobalEnv, package:stats, package:graphics, package:grDevices,
>> package:utils, package:datasets, package:methods, Autoloads, package:base
>>
>>
>
--
Prof. Dr. Martin Schlather
Institut für Mathematische Stochastik & Zentrum für Statistik
Georg-August-Universität Göttingen
Goldschmidtstr. 7, 5.111
D -- 37077 Göttingen
schlat...@math.uni-goettingen.de
http://www.stochastik.math.uni-goettingen.de/~schlather
http://zfs.uni-goettingen.de/
phone: +49 (0)551 39 17 2131 fax : +49 (0)551 39 13 505
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] uninitialised value in R (PR#13476)
Mathieu,
I do not understand what you mean in your email.
I am only interested in the cause of the valgrind
message in
> .Call("XXX")
[1] 1
> nd <- 3
> solve(diag(nd) , as.vector(1:nd))
[1] 1 2 3
> .Call("XXX")
==25734== Conditional jump or move depends on uninitialised value(s)
==25734==at 0x401620C: (within /lib/ld-2.8.so)
==25734==by 0x42825C3: (within /lib/libc-2.8.so)
==25734==by 0x4282989: _dl_sym (in /lib/libc-2.8.so)
==25734==by 0x417ADE7: (within /lib/libdl-2.8.so)
==25734==by 0x400DE25: (within /lib/ld-2.8.so)
==25734==by 0x417B0DB: (within /lib/libdl-2.8.so)
==25734==by 0x417AD72: dlsym (in /lib/libdl-2.8.so)
==25734==by 0x811012D: R_dlsym (Rdynload.c:787)
==25734==by 0x8110A98: R_FindSymbol (Rdynload.c:836)
==25734==by 0x816E41C: resolveNativeRoutine (dotcode.c:240)
==25734==by 0x817473A: do_dotcall (dotcode.c:825)
==25734==by 0x8194C12: Rf_eval (eval.c:487)
==25734==by 0x805B163: Rf_ReplIteration (main.c:257)
==25734==by 0x805B3E7: R_ReplConsole (main.c:306)
==25734==by 0x805B6D7: run_Rmainloop (main.c:966)
==25734==by 0x8058F80: main (Rmain.c:33)
==25734==
==25734== Conditional jump or move depends on uninitialised value(s)
==25734==at 0x4016217: (within /lib/ld-2.8.so)
==25734==by 0x42825C3: (within /lib/libc-2.8.so)
==25734==by 0x4282989: _dl_sym (in /lib/libc-2.8.so)
==25734==by 0x417ADE7: (within /lib/libdl-2.8.so)
==25734==by 0x400DE25: (within /lib/ld-2.8.so)
==25734==by 0x417B0DB: (within /lib/libdl-2.8.so)
==25734==by 0x417AD72: dlsym (in /lib/libdl-2.8.so)
==25734==by 0x811012D: R_dlsym (Rdynload.c:787)
==25734==by 0x8110A98: R_FindSymbol (Rdynload.c:836)
==25734==by 0x816E41C: resolveNativeRoutine (dotcode.c:240)
==25734==by 0x817473A: do_dotcall (dotcode.c:825)
==25734==by 0x8194C12: Rf_eval (eval.c:487)
==25734==by 0x805B163: Rf_ReplIteration (main.c:257)
==25734==by 0x805B3E7: R_ReplConsole (main.c:306)
==25734==by 0x805B6D7: run_Rmainloop (main.c:966)
==25734==by 0x8058F80: main (Rmain.c:33)
with the code originally given. Even if it is a problem
of the library ld, there might be interest by R to have
the problem detected.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] memory leak in split.screen
Hello, ## Configuring R with ./configure --with-tcl-config=/usr/lib/tcl8.5/tclConfig.sh --with-tk-config=/usr/lib/tk8.5/tkConfig.sh CFLAGS="-fsanitize=address -fsanitize=undefined -fno-sanitize=float-divide-by-zero,vptr " CXXFLAGS="-fsanitize=address -fsanitize=undefined -fno-sanitize=float-divide-by-zero,vptr " LD_FLAGS="-pthread -fopenmp-lclang_rt.asan_cxx-x86_64 -fopenmp=libgomp" CC="clang-3.8 -fsanitize=address -fsanitize=undefined -fno-sanitize=float-divide-by-zero,vptr" CXX="clang++-3.8 -fsanitize=address -fsanitize=undefined -fno-sanitize=float-divide-by-zero,vptr" ## I get in the interactive mode of R for n <- 4 ## the number is unimportant split.screen(c(n, n)) ## close.screen(all=TRUE) ## this command does not rectify the problem q() ## the following result: = ==14567==ERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x4d5018 (/usr/local/lib64/R/bin/exec/R+0x4d5018) #1 0x7f61cec8b56a (/usr/lib/x86_64-linux-gnu/libcairo.so.2+0x9b56a) SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s). ## I use Ubuntu 14.04.4 LTS, platform x86_64-pc-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Under development (unstable) major 3 minor 4.0 year 2016 month 07 day15 svn rev70918 language R version.string R Under development (unstable) (2016-07-15 r70918) nickname Unsuffered Consequences I would be happy to get any hint that explains this behaviour. The LeakSanitizer message appears in the interactive mode, but not in the batch mode. With kind regards, Martin Schlather __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
