Re: [R] Help with 'memory not mapped'

From: <jgarcia_at_ija.csic.es>
Date: Fri, 07 Mar 2008 13:09:20 +0100 (CET)

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
>

______________________________________________
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. Received on Fri 07 Mar 2008 - 12:11:29 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 07 Mar 2008 - 13:30:19 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-help. Please read the posting guide before posting to the list.

list of date sections of archive