[Rd] invalid alignment error in R-2.4.0

Tue Jul 11 12:15:33 CEST 2006

Hi

median(rep(1000,10)) does indeed give a similar error:

octopus:~/scratch% ./Rd/R.framework/Versions/2.4/Resources/bin/R -d gdb
GNU gdb 6.1-20040303 (Apple version gdb-434) (Wed Nov  2 17:28:16 GMT  
2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols  
for shared libraries ... done

(gdb) R
Starting program: /Users/rksh/scratch/Rd/R.framework/Versions/2.4/ 
Resources/bin/exec/R
Reading symbols for shared libraries ...................+ done

R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
Copyright (C) 2006 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

Reading symbols for shared  
libraries ..........................................................  
done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
 > median(rep(1000,10))

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000012
R_qsort (v=0x2891c70, i=1, j=2) at qsort-body.c:126
126             vt = v[i + 1];
(gdb) bt
#0  R_qsort (v=0x2891c70, i=1, j=2) at qsort-body.c:126
#1  0x0111e5d4 in do_qsort (call=0x1d365d4, op=0x1, args=0x1d31de4,  
rho=0x4) at qsort.c:89
#2  0x010c9a1c in do_internal (call=0x1d31de4, op=0x1, args=0x0,  
env=0x1d331f0) at names.c:1091
#3  0x01099bb4 in Rf_eval (e=0x1d3659c, rho=0x1d331f0) at eval.c:425
#4  0x0109ba10 in do_set (call=0x1d36548, op=0x180a390,  
args=0x1d36564, rho=0x1d331f0) at eval.c:1337
#5  0x01099bb4 in Rf_eval (e=0x1d36548, rho=0x1d331f0) at eval.c:425
#6  0x0109bc60 in do_begin (call=0x1d36510, op=0x180a2cc,  
args=0x1d3652c, rho=0x1d331f0) at eval.c:1101
#7  0x01099bb4 in Rf_eval (e=0x1d36510, rho=0x1d331f0) at eval.c:425
#8  0x01099bb4 in Rf_eval (e=0x1d363c0, rho=0x1d331f0) at eval.c:425
#9  0x0109ba10 in do_set (call=0x1d3636c, op=0x180a390,  
args=0x1d36388, rho=0x1d331f0) at eval.c:1337
#10 0x01099bb4 in Rf_eval (e=0x1d3636c, rho=0x1d331f0) at eval.c:425
#11 0x0109bc60 in do_begin (call=0x1d36e44, op=0x180a2cc,  
args=0x1d36350, rho=0x1d331f0) at eval.c:1101
#12 0x01099bb4 in Rf_eval (e=0x1d36e44, rho=0x1d331f0) at eval.c:425
#13 0x01099bb4 in Rf_eval (e=0x1d36d80, rho=0x1d331f0) at eval.c:425
#14 0x0109bc60 in do_begin (call=0x1d385b8, op=0x180a2cc,  
args=0x1d36d48, rho=0x1d331f0) at eval.c:1101
#15 0x01099bb4 in Rf_eval (e=0x1d385b8, rho=0x1d331f0) at eval.c:425
#16 0x0109d0ac in Rf_applyClosure (call=0x1d3d6d0, op=0x1d38318,  
arglist=0x1d330bc, rho=0x1d3ca54, suppliedenv=0x181d304) at eval.c:615
#17 0x01099d94 in Rf_eval (e=0x1d3d6d0, rho=0x1d3ca54) at eval.c:456
#18 0x0109b008 in Rf_DispatchOrEval (call=0x1d3d698, op=0x180b978,  
generic=0x11d74d0 "[", args=0x1d3d6b4, rho=0x1d3ca54, ans=0xbfffc0f8,  
dropmissing=0, argsevald=0) at eval.c:1758
#19 0x0115a828 in do_subset (call=0x1d3d698, op=0x180b978, args=0x0,  
rho=0x1d3ca54) at subset.c:527
#20 0x01099bb4 in Rf_eval (e=0x1d3d698, rho=0x1d3ca54) at eval.c:425
#21 0x01099a5c in Rf_eval (e=0x1d38f5c, rho=0x1d38024) at eval.c:402
#22 0x0109ae04 in Rf_evalList (el=0x1b4f9dc, rho=0x1d38024) at eval.c: 
1417
#23 0x010c9980 in do_internal (call=0x1b4f9dc, op=0x1,  
args=0x1b4fa14, env=0x1d38024) at names.c:1087
#24 0x01099bb4 in Rf_eval (e=0x1b4fa30, rho=0x1d38024) at eval.c:425
#25 0x0109d0ac in Rf_applyClosure (call=0x1d3d660, op=0x1b4fa84,  
arglist=0x1d38f78, rho=0x1d3ca54, suppliedenv=0x181d304) at eval.c:615
#26 0x01099d94 in Rf_eval (e=0x1d3d660, rho=0x1d3ca54) at eval.c:456
#27 0x0109ae7c in Rf_evalList (el=0x1d3d644, rho=0x1d3ca54) at eval.c: 
1427
#28 0x01099c04 in Rf_eval (e=0x1d3d628, rho=0x1d3ca54) at eval.c:435
#29 0x0109bc60 in do_begin (call=0x1d3d5f0, op=0x180a2cc,  
args=0x1d3d60c, rho=0x1d3ca54) at eval.c:1101
#30 0x01099bb4 in Rf_eval (e=0x1d3d5f0, rho=0x1d3ca54) at eval.c:425
#31 0x01099bb4 in Rf_eval (e=0x1d3d2c4, rho=0x1d3ca54) at eval.c:425
#32 0x0109bc60 in do_begin (call=0x1d3dc24, op=0x180a2cc,  
args=0x1d3d2a8, rho=0x1d3ca54) at eval.c:1101
#33 0x01099bb4 in Rf_eval (e=0x1d3dc24, rho=0x1d3ca54) at eval.c:425
#34 0x0109d0ac in Rf_applyClosure (call=0x1d3ee00, op=0x1d3f0a0,  
arglist=0x1d3ca00, rho=0x181d2e8, suppliedenv=0x181d304) at eval.c:615
#35 0x01099d94 in Rf_eval (e=0x1d3ee00, rho=0x181d2e8) at eval.c:456
#36 0x010b7d30 in Rf_ReplIteration (rho=0x181d2e8, savestack=0,  
browselevel=0, state=0xbfffed88) at main.c:254
#37 0x010b7e88 in R_ReplConsole (rho=0x181d2e8, savestack=0,  
browselevel=0) at main.c:302
#38 0x010b8198 in run_Rmainloop () at main.c:913
#39 0x00002cec in main (ac=42540144, av=0x1) at Rmain.c:33
(gdb)

On 11 Jul 2006, at 10:54, Prof Brian Ripley wrote:

> On Tue, 11 Jul 2006, Martin Maechler wrote:
>
>> Hi Robin,
>>
>> thanks for the extra info.  I have no clue what the problem
>> might be.
>>
>> But from R-level debugging (and the R traceback you wrote
>> originally),
>> I assume you could trigger the problem already by a simple
>>
>>   median(rep(1000, 10))
>>
>> is that the case? If yes, please follow up on R-devel.
>
> I don't see why you assume so: there are multitudinous paths through
> qsort.
>
>> In any case, let's wait for others (Mac specialists and/or other
>> R-core members) to voice ideas.
>
> I checked this under valgrind, which normally shows up such errors,  
> and
> found nothing, even with gctorture on (and valgrind instrumentation of
> R's memory management on).
>
> You used the dput and Robin used load(), so presumably on not  
> exactly the
> same object.  I think Robin needs to test what he actually gave us,  
> to be
> sure.  If that is the case, I suspect the compiler.
>
>>
>>

--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
  tel  023-8059-7743