[R] Help with 'memory not mapped'
jgarcia at ija.csic.es
jgarcia at ija.csic.es
Fri Mar 7 13:09:20 CET 2008
Dear Ramon,
I'm afraid I'm the author of the C function. Although I'm not a 'real'
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.
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
>
More information about the R-help
mailing list