[R] Help with 'memory not mapped'
Ramon Diaz-Uriarte
rdiaz02 at gmail.com
Fri Mar 7 13:24:45 CET 2008
Dear Javier,
On Fri, Mar 7, 2008 at 1:09 PM, <jgarcia at ija.csic.es> wrote:
> Dear Ramon,
> I'm afraid I'm the author of the C function. Although I'm not a 'real'
Oh, oh... that's too bad. There is not anyone else to blame, then :-).
> programmer I need to do some programming in my research work.
> As you say, I've used MAKEFLAGS="CFLAGS=-O1", and valgrind, with the
> expression you've said.
>
When looking at the valgrind output, search for lines where your
library is mentioned (rain_runoff_modelv ?). Ignore everything else
about libraries that are not your own (e.g., system or R). Just stick
to the issues that relate to your code.
>From the output you've sent, there is "Conditional jump or move
depends on uninitialised value(s)" on
==6464== by 0x88ACE24: rainfallrunoffmodel (rain_runoff_modelv1_2.c:517)
but more worrisome than that (and I think the immediate cause of the
segfault) is:
> ==6464== Invalid write of size 8
> ==6464== at 0x88AD228: rainfallrunoffmodel (rain_runoff_modelv1_2.c:595)
so it seems your code is trying to write to a place it shouldn't.
Depending on when, what, and to where exactly it is trying to write,
your code will crash sooner or later.
HTH,
R.
> The content of the log file contains three blocks of the type:
> -----
> ==6464== Invalid read of size 8
> ==6464== at 0x401433E: (within /lib64/ld-2.6.1.so)
> ==6464== by 0x4009631: (within /lib64/ld-2.6.1.so)
> ==6464== by 0x5CAA804: (within /lib64/libc-2.6.1.so)
> ==6464== by 0x59B0143: (within /lib64/libdl-2.6.1.so)
> ==6464== by 0x400C8E5: (within /lib64/ld-2.6.1.so)
> ==6464== by 0x59B036C: (within /lib64/libdl-2.6.1.so)
> ==6464== by 0x59B00F9: dlsym (in /lib64/libdl-2.6.1.so)
> ==6464== by 0x54F60C: R_local_dlsym (dynload.c:214)
> ==6464== by 0x4172F8: AddDLL (Rdynload.c:565)
> ==6464== by 0x4179F3: do_dynload (Rdynload.c:895)
> ==6464== by 0x4C3A44: do_internal (names.c:1120)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== Address 0x64A7608 is 24 bytes inside a block of size 27 alloc'd
> ==6464== at 0x4C21D06: malloc (in
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==6464== by 0x4172CC: AddDLL (Rdynload.c:557)
> ==6464== by 0x4179F3: do_dynload (Rdynload.c:895)
> ==6464== by 0x4C3A44: do_internal (names.c:1120)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x497CEB: Rf_applyClosure (eval.c:669)
> ==6464== by 0x495C87: Rf_eval (eval.c:507)
> ==6464== by 0x4B4C04: Rf_ReplIteration (main.c:263)
> ==6464== by 0x4B4EB7: R_ReplConsole (main.c:312)
> ==6464== by 0x4B518F: run_Rmainloop (main.c:975)
> ==6464== by 0x414AF7: main (Rmain.c:35)
> ------
>
> and after a lot of block of the type 'uninitialised value', it finishes
> like this:
>
> -----
> ==6464== Conditional jump or move depends on uninitialised value(s)
> ==6464== at 0x5BF324C: (within /lib64/libc-2.6.1.so)
> ==6464== by 0x5BFB8FA: __printf_fp (in /lib64/libc-2.6.1.so)
> ==6464== by 0x5BF5587: vfprintf (in /lib64/libc-2.6.1.so)
> ==6464== by 0x5BFE509: printf (in /lib64/libc-2.6.1.so)
> ==6464== by 0x88ACE24: rainfallrunoffmodel (rain_runoff_modelv1_2.c:517)
> ==6464== by 0x4750D1: do_dotcall (dotcode.c:1136)
> ==6464== by 0x495F36: Rf_eval (eval.c:489)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x497CEB: Rf_applyClosure (eval.c:669)
> ==6464== by 0x495C87: Rf_eval (eval.c:507)
> ==6464== by 0x499B6E: do_set (eval.c:1407)
> ==6464==
> ==6464== Invalid write of size 8
> ==6464== at 0x88AD228: rainfallrunoffmodel (rain_runoff_modelv1_2.c:595)
> ==6464== by 0x4750D1: do_dotcall (dotcode.c:1136)
> ==6464== by 0x495F36: Rf_eval (eval.c:489)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x497CEB: Rf_applyClosure (eval.c:669)
> ==6464== by 0x495C87: Rf_eval (eval.c:507)
> ==6464== by 0x499B6E: do_set (eval.c:1407)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49938D: do_for (eval.c:1058)
> ==6464== Address 0x26C7E9E0 is not stack'd, malloc'd or (recently) free'd
> ==6464==
> ==6464== Syscall param write(buf) points to uninitialised byte(s)
> ==6464== at 0x5C6AC40: write (in /lib64/libc-2.6.1.so)
> ==6464== Address 0x402A3DB is not stack'd, malloc'd or (recently) free'd
> ==6464==
> ==6464== ERROR SUMMARY: 35923 errors from 210 contexts (suppressed: 244
> from 3)
> ==6464== malloc/free: in use at exit: 284,245,283 bytes in 14,390 blocks.
> ==6464== malloc/free: 89,306 allocs, 74,916 frees, 1,051,054,834 bytes
> allocated.
> ==6464== For counts of detected errors, rerun with: -v
> ==6464== searching for pointers to 14,390 not-freed blocks.
> ==6464== checked 141,122,600 bytes.
> ==6464==
> ==6464==
> ==6464== 64 bytes in 16 blocks are definitely lost in loss record 12 of 54
> ==6464== at 0x4C21D06: malloc (in
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==6464== by 0x4C21D80: realloc (in
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==6464== by 0x51BE04: parse_expression (regex.c:5205)
> ==6464== by 0x51BFF3: parse_branch (regex.c:4715)
> ==6464== by 0x51C07F: parse_reg_exp (regex.c:4667)
> ==6464== by 0x51C9A6: Rf_regcomp (regex.c:4636)
> ==6464== by 0x43BD06: do_gsub (character.c:1222)
> ==6464== by 0x4C3A44: do_internal (names.c:1120)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x497CEB: Rf_applyClosure (eval.c:669)
> ==6464==
> ==6464==
> ==6464== 87 bytes in 2 blocks are definitely lost in loss record 13 of 54
> ==6464== at 0x4C21D06: malloc (in
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==6464== by 0x8AD7DBE: G_strdup (strings.c:195)
> ==6464== by 0x8AD5A78: G_site_get_head (sites.c:818)
> ==6464== by 0x8AD6808: sitesget (sitesget.c:66)
> ==6464== by 0x47757D: do_dotcall (dotcode.c:868)
> ==6464== by 0x495F36: Rf_eval (eval.c:489)
> ==6464== by 0x499B6E: do_set (eval.c:1407)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464==
> ==6464==
> ==6464== 1,024 bytes in 1 blocks are possibly lost in loss record 26 of 54
> ==6464== at 0x4C21D06: malloc (in
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==6464== by 0x8ABD7A9: G_malloc (alloc.c:61)
> ==6464== by 0x8AD6506: G_site_new_struct (sites.c:309)
> ==6464== by 0x8AD6BB2: sitesget (sitesget.c:125)
> ==6464== by 0x47757D: do_dotcall (dotcode.c:868)
> ==6464== by 0x495F36: Rf_eval (eval.c:489)
> ==6464== by 0x499B6E: do_set (eval.c:1407)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464==
> ==6464==
> ==6464== 3,756 bytes in 1 blocks are definitely lost in loss record 35 of 54
> ==6464== at 0x4C2102F: calloc (in
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==6464== by 0x8ABD7E3: G_calloc (alloc.c:75)
> ==6464== by 0x8AD27E4: rastput (rastput.c:83)
> ==6464== by 0x477240: do_dotcall (dotcode.c:915)
> ==6464== by 0x495F36: Rf_eval (eval.c:489)
> ==6464== by 0x499B6E: do_set (eval.c:1407)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464==
> ==6464==
> ==6464== 23,916 bytes in 25 blocks are definitely lost in loss record 44
> of 54
> ==6464== at 0x4C21D06: malloc (in
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==6464== by 0x8ABD7A9: G_malloc (alloc.c:61)
> ==6464== by 0x8AD7B22: G_store (store.c:17)
> ==6464== by 0x8ACD2E4: G_set_program_name (progrm_nme.c:39)
> ==6464== by 0x8AD4B78: R_G_init (R_G_init.c:16)
> ==6464== by 0x8AD17D8: rastget (rastget.c:44)
> ==6464== by 0x47757D: do_dotcall (dotcode.c:868)
> ==6464== by 0x495F36: Rf_eval (eval.c:489)
> ==6464== by 0x499B6E: do_set (eval.c:1407)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464== by 0x49698F: do_begin (eval.c:1159)
> ==6464== by 0x495D65: Rf_eval (eval.c:463)
> ==6464==
> ==6464== LEAK SUMMARY:
> ==6464== definitely lost: 27,823 bytes in 44 blocks.
> ==6464== possibly lost: 1,024 bytes in 1 blocks.
> ==6464== still reachable: 284,216,436 bytes in 14,345 blocks.
> ==6464== suppressed: 0 bytes in 0 blocks.
> ==6464== Reachable blocks (those to which a pointer was found) are not shown.
> ==6464== To see them, rerun with: --leak-check=full --show-reachable=yes
> -----
> of course, I do not pretend that anyone else debug my code, but perhaps at
> the view of this you can give me another clue or a general advice.
>
> Still, I don't understand why the code just crashes sometimes.
>
> Thanks,
>
> Javier
> -------------------
>
>
>
>
>
>
>
>
>
> > Dear Javier,
> >
> > From your description, it seems you are not the author of the C
> > function rrfunc, which is where the problem is probably located (the
> > segmentation fault is most likely a pointer related problem where the
> > C code is trying to do something with memory it should not be trying
> > to do). Depending on the exact settings of your simulation, the state
> > of your machine, etc
> > the problem will show up at one point or another. I'd get in touch
> > with the author of the C code and let her/him know that there is a
> > problem in it. Most of these are very quickly located using valgrind.
> > Search on the archives and the manual (Writing R extensions) but a
> > call such as
> >
> > R -d "valgrind --tool=memcheck --leak-check=full
> > --log-file=marian.valgrind.log" --vanilla < mariam1_2.R >
> > mariam1_2.with.valgrind.Rout
> >
> > after compiling the C code with the "-O1" (not -O2, as per default) flag.
> >
> > HTH,
> >
> > R.
> >
> >
> > On Fri, Mar 7, 2008 at 10:26 AM, <jgarcia at ija.csic.es> wrote:
> >> Hi,
> >> I'm no expert programmer at all;
> >> I'm running an R script ("mariam1_2.R"). This scripts calls another
> >> script, which contains an R function, which .Call some C code.
> >> It runs several times without any problem, but sometimes I get the
> >> error:
> >> -------
> >> *** caught segfault ***
> >> address 0x1c404ec8, cause 'memory not mapped'
> >>
> >> Traceback:
> >> 1: .Call("rrfunc", as.double(dx), as.integer(nrows),
> >> as.integer(ncols),
> >> as.double(deltadt), as.character(binmaps), as.integer(ldd),
> >> as.double(downst),as.integer(outl), as.double(maxinte), as.double(nmn))
> >> 2: rrfuncR(dx, nrows, ncols, delta.t,binmaps.pathed,ldd,downst,
> >> out.index,interc,n.man)
> >> 3: eval.with.vis(expr, envir, enclos)
> >> 4: eval.with.vis(ei, envir)
> >> 5: source("rrprogv1_2.R")
> >> 6: eval.with.vis(expr, envir, enclos)
> >> 7: eval.with.vis(ei, envir)
> >> 8: source("mariam1_2.R")
> >>
> >> Possible actions:
> >> 1: abort (with core dump, if enabled)
> >> 2: normal R exit
> >> 3: exit R without saving workspace
> >> 4: exit R saving workspace
> >> Selection:
> >> ---------------
> >> I've seen something related in the documentation, but it is not easy to
> >> understand it for me. I'm trying to perform a Monte Carlo analysis that
> >> calls the function iteratively. My question is why sometimes I can call
> >> forty or fifty times the function without any problem, and other times
> >> it
> >> crashes at the first, second or 6th time. Can you give me any advice?
> >>
> >> Thanks and best regards,
> >> Javier
> >>
> >> ______________________________________________
> >> R-help at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-help
> >> PLEASE do read the posting guide
> >> http://www.R-project.org/posting-guide.html
> >> and provide commented, minimal, self-contained, reproducible code.
> >>
> >
> >
> >
> > --
> > Ramon Diaz-Uriarte
> > Statistical Computing Team
> > Structural Biology and Biocomputing Programme
> > Spanish National Cancer Centre (CNIO)
> > http://ligarto.org/rdiaz
> >
>
>
--
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz
More information about the R-help
mailing list