[R-SIG-Mac] Making package "frontier" available for Mac: debugging Fortran code

Simon Urbanek simon.urbanek at r-project.org
Mon Dec 3 20:05:04 CET 2012


Arne,

unfortunately I don't think I can help you with Fortran code, but this is the trace from the crash:

> example(summary.frontier)
[...]
smmry.>    # Efficiency Effects Frontier
smmry.>    rice2 <- sfa( log( PROD ) ~ log( AREA ) + log( LABOR ) + log( NPK ) |
smmry.+       EDYRS + BANRAT, data = riceProdPhil )

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x01a55000
0x00ff8433 in info (nstartval=@0x260ce80, startval=0x260d540, nrowdata=@0x260cec0, ncoldata=@0x260cf20, datatable=0x1a4f018, nparamtotal=@0x260d0e0, ob=0x32d3080, gb=0x32d3118, fxs=@0xbfffac68, y=0x32d31b0, h=0x27b8618) at front41.f:818
818	      xxd(i)=dataTable(k,2+i)
(gdb) p i
$1 = 7
Current language:  auto; currently fortran
(gdb) p k
$2 = 318
(gdb) bt
#0  0x00ff8433 in info (nstartval=@0x260ce80, startval=0x260d540, nrowdata=@0x260cec0, ncoldata=@0x260cf20, datatable=0x1a4f018, nparamtotal=@0x260d0e0, ob=0x32d3080, gb=0x32d3118, fxs=@0xbfffac68, y=0x32d31b0, h=0x27b8618) at front41.f:818
#1  0x00ffcbe7 in front41 (imarg=@0x260fd20, ipcarg=@0x260fda0, nnarg=@0x260d340, ntarg=@0x260d360, nobarg=@0x260d380, nbarg=@0x260d3a0, nmuarg=@0x260fdc0, netaarg=@0x260d3c0, iprintarg=@0x260d3e0, indicarg=@0x260d400, tolarg=@0x260d420, tol2arg=@0x260d440, bignumarg=@0x260d460, step1arg=@0x260d480, igrid2arg=@0x260ce20, gridnoarg=@0x260d4a0, maxitarg=@0x260d4c0, bmuarg=@0x260d4e0, mrestartarg=@0x260d500, frestartarg=@0x260d520, nrestartarg=@0x260ce40, nstartval=@0x260ce80, startval=0x260d540, nrowdata=@0x260cec0, ncoldata=@0x260cf20, datatable=0x1a4f018, nparamtotal=@0x260d0e0, ob=0x32d3080, gb=0x32d3118, startlogl=@0x260d560, y=0x32d31b0, h=0x27b8618, fmlelogl=@0x260d580, niter=@0x260d260, icodearg=@0x260d280) at front41.f:74
#2  0x0046c5ab in do_dotCode (call=0x12c1c60, op=0x101b2d0, args=0x262b024, env=0x31e74b4) at ../../../../R-2.15-branch/src/main/dotcode.c:1901
#3  0x0049a681 in Rf_eval (e=0x12c1c60, rho=0x31e74b4) at ../../../../R-2.15-branch/src/main/eval.c:494
#4  0x0049d9c6 in do_set (call=0x12c1bd4, op=0x100e2a8, args=0x12c1bf0, rho=0x31e74b4) at ../../../../R-2.15-branch/src/main/eval.c:1717
#5  0x0049a482 in Rf_eval (e=0x12c1bd4, rho=0x31e74b4) at ../../../../R-2.15-branch/src/main/eval.c:468
#6  0x0049c362 in do_begin (call=0x1591c00, op=0x100e1ac, args=0x12c1640, rho=0x31e74b4) at ../../../../R-2.15-branch/src/main/eval.c:1415
#7  0x0049a482 in Rf_eval (e=0x1591c00, rho=0x31e74b4) at ../../../../R-2.15-branch/src/main/eval.c:468
#8  0x0049f8bd in Rf_applyClosure (call=0x21f3580, op=0x11b9d9c, arglist=0x31e673c, rho=0x102519c, suppliedenv=0x10251b8) at ../../../../R-2.15-branch/src/main/eval.c:861
#9  0x0049a382 in Rf_eval (e=0x21f3580, rho=0x102519c) at ../../../../R-2.15-branch/src/main/eval.c:512
#10 0x0049d9c6 in do_set (call=0x21f35d4, op=0x100e2a8, args=0x21f35b8, rho=0x102519c) at ../../../../R-2.15-branch/src/main/eval.c:1717
#11 0x0049a482 in Rf_eval (e=0x21f35d4, rho=0x102519c) at ../../../../R-2.15-branch/src/main/eval.c:468
#12 0x0049b1aa in do_eval (call=0x10dcad0, op=0x101d394, args=0x31e6800, rho=0x31e6838) at ../../../../R-2.15-branch/src/main/eval.c:2107

The code crashes at exactly the same line in 64-bit mode as well, so it's likely a real bug. valgrind seems to confirm that it's a OOB read bug in front41.f at 818:

smmry.>    # Efficiency Effects Frontier
smmry.>    rice2 <- sfa( log( PROD ) ~ log( AREA ) + log( LABOR ) + log( NPK ) |
smmry.+       EDYRS + BANRAT, data = riceProdPhil )
==76290== Invalid read of size 8
==76290==    at 0x867E433: info_ (front41.f:818)
==76290==    by 0x8682BE6: front41_ (front41.f:74)
==76290==    by 0x46C5AA: do_dotCode (dotcode.c:1901)
==76290==    by 0x49A680: Rf_eval (eval.c:494)
==76290==    by 0x49D9C5: do_set (eval.c:1717)
==76290==    by 0x49A481: Rf_eval (eval.c:468)
==76290==    by 0x49C361: do_begin (eval.c:1415)
==76290==    by 0x49A481: Rf_eval (eval.c:468)
==76290==    by 0x49F8BC: Rf_applyClosure (eval.c:861)
==76290==    by 0x49A381: Rf_eval (eval.c:512)
==76290==    by 0x49D9C5: do_set (eval.c:1717)
==76290==    by 0x49A481: Rf_eval (eval.c:468)
==76290==  Address 0x8b81288 is 0 bytes after a block of size 22,040 alloc'd
==76290==    at 0x16483: malloc (vg_replace_malloc.c:236)
==76290==    by 0x4DE762: Rf_allocVector (memory.c:2380)
==76290==    by 0x406A48: Rf_allocMatrix (array.c:194)
==76290==    by 0x407AC9: do_matrix (array.c:128)
==76290==    by 0x4908D7: bcEval (eval.c:4449)
==76290==    by 0x49A145: Rf_eval (eval.c:399)
==76290==    by 0x49F8BC: Rf_applyClosure (eval.c:861)
==76290==    by 0x49A381: Rf_eval (eval.c:512)
==76290==    by 0x49B8CC: Rf_evalList (eval.c:1831)
==76290==    by 0x49A54A: Rf_eval (eval.c:487)
==76290==    by 0x49D9C5: do_set (eval.c:1717)
==76290==    by 0x49A481: Rf_eval (eval.c:468)
==76290== 

Cheers,
Simon


On Dec 3, 2012, at 10:35 AM, Arne Henningsen <arne.henningsen at gmail.com> wrote:

> Dear Mac users
> 
> I am the maintainer of the R package "frontier." Some Mac users made
> me aware of that this package is not available for their system [1],
> because its Fortran code causes a segmentation fault when "R CMD
> check" runs the example code. This error neither occurs on MS-Windows
> nor on GNU-Linux systems. As I do not have access to a Mac system, I
> cannot debug this error and I wonder if someone on this list could
> help me to debug and fix this error. Thanks a lot in advance!
> 
> [1] http://cran.r-project.org/web/packages/frontier/index.html
> 
> [2] http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/frontier-00check.html
> 
> Best wishes from Copenhagen,
> Arne
> 
> -- 
> Arne Henningsen
> http://www.arne-henningsen.name
> 
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
> 



More information about the R-SIG-Mac mailing list