Skip to content

Help with 'memory not mapped'

4 messages · Ramon Diaz-Uriarte, Javier Garcia-Pintado

Javier Garcia-Pintado
# 
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
Ramon Diaz-Uriarte
# 
Dear Javier,
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:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Javier Garcia-Pintado
    

    

      
      #
    

  


  

      
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
-------------------

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ramon Diaz-Uriarte
    

    

      
      #
    

  


  

      
Dear Javier,

        
On Fri, Mar 7, 2008 at 1:09 PM,  <jgarcia at ija.csic.es> wrote:

            

      
      
      
    

        
Oh, oh... that's too bad. There is not anyone else to blame, then :-).

            

      
      
      
    

        
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.

            

      
      
      
    

        
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:

            

      
      
      
    

        
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.