[R] Mysterious seg fault.

[Rolf Turner]

On 13/08/18 12:03, Duncan Murdoch wrote:

<SNIP>

>> So I did:
>>
>> /usr/local/bin/valgrind R
> 
> I believe on your system R is a script, so you can't run valgrind this 
> way.  It's just debugging bash, not R.  You need to use
> 
> R -d valgrind
> 
> (though with your weird path problems, you might need a fully qualified 
> /usr/local/bin/valgrind there).
> 
> You run gdb the same way:
> 
> R -d gdb
> 
> and then give the command "r" to gdb to start R.  It will give a report 
> when you get the segfault.  I don't know which report will be more 
> informative.

<SNIP>

Thanks Duncan.  I did as you said with valgrind and got output that is 
probably more relevant.  However it is still opaque to me.  I have no 
idea how to use it to track down the error that I am making in the code.

> xxx <- get.hgl(p3,2,yyy)
> ==20088== Invalid read of size 8
> ==20088==    at 0x5116CD: Rf_allocVector3 (memory.c:2539)
> ==20088==    by 0x4B40FF: Rf_allocVector (Rinlinedfuns.h:577)
> ==20088==    by 0x4B40FF: do_missing (envir.c:2265)
> ==20088==    by 0x4CA383: bcEval (eval.c:6801)
> ==20088==    by 0x4D99EF: Rf_eval (eval.c:624)
> ==20088==    by 0x4DB172: R_execClosure (eval.c:1773)
> ==20088==    by 0x4D0E6E: bcEval (eval.c:6749)
> ==20088==    by 0x4D99EF: Rf_eval (eval.c:624)
> ==20088==    by 0x4DB172: R_execClosure (eval.c:1773)
> ==20088==    by 0x4D0E6E: bcEval (eval.c:6749)
> ==20088==    by 0x4D99EF: Rf_eval (eval.c:624)
> ==20088==    by 0x4DB172: R_execClosure (eval.c:1773)
> ==20088==    by 0x4D99A1: Rf_eval (eval.c:747)
> ==20088==  Address 0x3fca86ccfb7de9cc is not stack'd, malloc'd or (recently) free'd
> ==20088== 
> 
>  *** caught segfault ***
> address (nil), cause 'unknown'
> ==20088== Invalid read of size 8
> ==20088==    at 0x511B23: Rf_allocVector3 (memory.c:2691)
> ==20088==    by 0x49137A: Rf_allocVector (Rinlinedfuns.h:577)
> ==20088==    by 0x49137A: deparse1WithCutoff (deparse.c:268)
> ==20088==    by 0x492EAF: Rf_deparse1m (deparse.c:197)
> ==20088==    by 0x4BA99C: R_GetTraceback (errors.c:1409)
> ==20088==    by 0x5053CE: sigactionSegv (main.c:592)
> ==20088==    by 0x6CA738F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so)
> ==20088==    by 0x5116CC: Rf_allocVector3 (memory.c:2539)
> ==20088==  Address 0x3fca86ccfb7de9cc is not stack'd, malloc'd or (recently) free'd
> ==20088== 
> ==20088== 
> ==20088== Process terminating with default action of signal 11 (SIGSEGV)
> ==20088==  General Protection Fault
> ==20088==    at 0x511B23: Rf_allocVector3 (memory.c:2691)
> ==20088==    by 0x49137A: Rf_allocVector (Rinlinedfuns.h:577)
> ==20088==    by 0x49137A: deparse1WithCutoff (deparse.c:268)
> ==20088==    by 0x492EAF: Rf_deparse1m (deparse.c:197)
> ==20088==    by 0x4BA99C: R_GetTraceback (errors.c:1409)
> ==20088==    by 0x5053CE: sigactionSegv (main.c:592)
> ==20088==    by 0x6CA738F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so)
> ==20088==    by 0x5116CC: Rf_allocVector3 (memory.c:2539)
> ==20088== 
> ==20088== HEAP SUMMARY:
> ==20088==     in use at exit: 210,111,063 bytes in 57,981 blocks
> ==20088==   total heap usage: 106,693 allocs, 48,712 frees, 349,208,345 bytes allocated
> ==20088== 
> ==20088== LEAK SUMMARY:
> ==20088==    definitely lost: 0 bytes in 0 blocks
> ==20088==    indirectly lost: 0 bytes in 0 blocks
> ==20088==      possibly lost: 0 bytes in 0 blocks
> ==20088==    still reachable: 210,111,063 bytes in 57,981 blocks
> ==20088==                       of which reachable via heuristic:
> ==20088==                         newarray           : 4,264 bytes in 1 blocks
> ==20088==         suppressed: 0 bytes in 0 blocks
> ==20088== Rerun with --leak-check=full to see details of leaked memory
> ==20088== 
> ==20088== For counts of detected and suppressed errors, rerun with: -v
> ==20088== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
> Segmentation fault (core dumped)

Doesn't mean a thing to me, I'm afraid.  Does it mean anything to you?
I have not (yet) "rerun with: -v".  I suspect that this would not help.

I guess I'll try to get gdb going next, and see if that provides more 
lucid output.

cheers,

Rolf

-- 
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276