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, <[EMAIL PROTECTED]> 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@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@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.