Skip to content

followup on rgdal - invalid alignment error

10 messages · Scott Mitchell, Roger Bivand, Tim Keitt

Original
Scott Mitchell
# 
After sending my last post, detailing my system setup with a working  
R/GDAL/rgdal installation on a Mac, I played a bit more and came  
across a glitch when I tried example(readGDAL) on the fresh build.

It gets through translating the data set and the image command, but  
then on summary() I get:

rdGDAL> summary(x)

*** caught bus error ***
address 0x17, cause 'invalid alignment'

Traceback:
1: sort(x, partial = unique(c(lo, hi)))
2: quantile.default(object)
3: stats::quantile(object)
4: summary.default(X[[1]], ...)
5: FUN(X[[1]], ...)
6: lapply(as.list(object), summary, maxsum = maxsum, digits =  
12,     ...)
7: summary.data.frame(object at att)
8: summary(object at data)
9: summary(object at data)
10: summary(x)
11: summary(x)
12: eval.with.vis(expr, envir, enclos)
13: eval.with.vis(ei, envir)
14: source(zfile, local, echo = echo, prompt.echo = prompt.echo,      
verbose = verbose, max.deparse.length = 250, encoding = encoding)
15: example(readGDAL)

Possible actions:
1: abort (with core dump)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection:

A byte-ordering issue???

Any suggestions?

Scott




----
Scott Mitchell, Assistant Professor, Carleton University
Department of Geography & Environmental Studies, Loeb B443A
& Geomatics and Landscape Ecology Research Laboratory, Nesbitt 340
Mailing:  Loeb B349, 1125 Colonel By Dr., Ottawa, ON K1S 5B6 Canada
+1-613-520-2600 x2695 Fax: +1-613-520-4301 Scott_Mitchell at carleton.ca
Roger Bivand
#
On Fri, 8 Sep 2006, Scott W Mitchell wrote:

            

      
      
      
    

        
Scott:

Thanks very much for your detailed descriptions, and I hope updating to 
try to help the original questioner hasn't broken things you need now.

            

      
      
      
    

        
Can you re-run the example code by hand, line by line (copy & paste for
example)? From what you write, image displays correctly, is that right?  
That suggests that the data has been read correctly, otherwise it would
not have displayed? Which image is this - several are read in the example?  
Does example(GDAL.open) run smoothly? Something in the first band of the
data is causing sort to choke, could it be an NA? can you copy out the 
band to a regular vector, and save it to file as an R object? If it is a 
value in the band, it should be saved in a platform independent way. GDAL 
also swaps to suit endianness.

Roger

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Tim Keitt
    

    

      
      #
    

  


  

      
One possibility is that the size of the GDAL data type is not the same
as the size of the R data type. This will definitely cause problems as
allocation is done by R and the pointer is cast to void when passed to
GDAL. My original C++ code simply assumes that both are 32-bit (or at
least equivalent size), but things will break if they are different.
(Roger -- you probably noticed the "fix me!" comments to myself in
there -- that was what I was talking about.)

GDAL data types include the size information (e.g., UInt32), but R
simply uses INTSXP and so on. Does anyone know how one determines for
any particular build of R the size of these R types? If I know the
size of INTSXP, then I can pick the corresponding GDAL data type.

THK

        
On 9/8/06, Roger Bivand <Roger.Bivand at nhh.no> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
On Fri, 8 Sep 2006, Tim Keitt wrote:

        

            

      
      
      
    

        
(about line 750 in src/gdal-bindings.cpp)

Yes, but this is an example that is run very often on i386 at least, so 
I'm not sure why it should show up now on an other-endian platform? GDAL 
knows about endian-ness, doesn't it? Without access to the specific 
platform and build train, it would be difficult to debug? What else do we 
know about the platform? Is a G5 64-bit (ie. how big is an int)? What 
happens now is that sizeof(int) * ncells or sizeof(double) * ncells is 
made available for copying.

Note that there were changes in this code recently because 2.4.0 imposes 
stronger type checking, but I don't think that is it?

Roger

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Tim Keitt
    

    

      
      #
    

  


  

      
On 9/8/06, Roger Bivand <Roger.Bivand at nhh.no> wrote:

            

      
      
      
    

        
If its 64 bit, this is likely the problem. GDAL's types are the same
size regardless of the platform, but my guess is that R's types change
size.

            

      
      
      
    

        
Nope. Shouldn't be a problem.

THK

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Scott Mitchell
    

    

      
      #
    

  


  

      
On 8-Sep-06, at 14:23, Roger Bivand wrote:

        

            

      
      
      
    

        
Yes, sorry, it does display the image, and then chokes on the summary 
(x) - this is in the FIRST part of the example - identical behaviour  
when run manually.

            

      
      
      
    

        
No.

OK, before I got any further through your suggestions, I thought I  
should try eliminating the version of gcc used as a potential cause,  
as mentioned in my followup message to the original post.

I have just downloaded the R binary for OS 10.4.4+, which also comes  
with a version of gcc with the bug fixed, and then I reinstalled  
rgdal, sp, and VR from source, and sure enough, now I get through the  
examples fine.  So, it's solved.  At least now the warning against  
using recent Apple-supplied gcc for this will now be documented in  
this list, as it was in R-sig-mac.

The good news is that I don't imagine this will apply at all to  
Jonathan, running OS 10.3.9 and (I presume) older development tools  
(i.e. https://stat.ethz.ch/pipermail/r-sig-geo/2006-September/ 
001263.html ), since I'm almost certain that this bug in the Apple- 
supplied gcc did not exist prior to XCode-2.2.x.

That would make sense with my "alignment issue", since this version  
of the dev tools added support for universal binaries to handle the  
new architecture to the general public.  Hopefully they'll fix it  
soon.  In the meantime, the gcc supplied by the Mac team at CRAN does  
the trick.

Cheers,
Scott

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
On Fri, 8 Sep 2006, Tim Keitt wrote:

        

            

      
      
      
    

        
Luckily this time the problem is resolved, but I agree that we'll need to 
work out what happens when R thinks that int is long. I don't have access 
to any 64-bit platforms to try this out, but from the lack of reports - 
and some people are running on 64-bit - maybe this just gets done 
correctly?

Roger

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Scott Mitchell
    

    

      
      #
    

  


  

      
On 8 Sep 2006, at 15:27, Roger Bivand wrote:

        

            

      
      
      
    

        
I can certainly provide access to a test system and/or follow  
instructions for testing if that would help.  If you'll be in  
Lausanne next week, we could discuss this more there.

            

      
      
      
    

        
Yes, G5 is 64 bit, but if I understand correctly, one needs to  
"request" this capability when compiling.  I see that sizeof(int)  
returns a value of 4 if I run it on a G5 or a G4 (which is not 64  
bit)...

Actually, looking a little deeper and reading the gcc man page, if I  
just compile with defaults, int is 4 and long is 4, but if I use -m64  
when compiling, int is still 4 but long is 8.

The powerpc build uses the same flags as the i386 for 32/64 (from man  
gcc):

        -m32
        -m64
            Generate code for 32-bit or 64-bit environments of Darwin  
and SVR4
            targets (including GNU/Linux).  The 32-bit environment  
sets int,
            long and pointer to 32 bits and generates code that runs  
on any
            PowerPC variant.  The 64-bit environment sets int to 32  
bits and
            long and pointer to 64 bits, and generates code for  
PowerPC64, as
            for -mpowerpc64.

Hope that helps,
Scott



------
Scott W. Mitchell	Scott_Mitchell at carleton.ca
Geomatics and Landscape Ecology Research Laboratory
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building
Ottawa, ON Canada K1S 5B6
+1-613-520-2600 ext 2695

  
  


  


      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
On Fri, 8 Sep 2006, Scott W Mitchell wrote:

            

      
      
      
    

        
Yes, I'll be in Lausanne, which for those not aware of it, is a meeting 
between and about software projects in "Free And Open Source Software for 
Geoinformatics", http://www.foss4g2006.org/, all next week. The R/GRASS 
interface is being presented in a workshop, together with rgdal and 
friends, on Tuesday afternoon, 12 September.

            

      
      
      
    

        
This seems to happen in config.h when R is built, and the details are I 
think in the constants returned by .Machine. We can follow this up in 
Lausanne.

Roger

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Tim Keitt
    

    

      
      #
    

  


  

      
I found the type size defs in Rinternals.h. They are
R_XDR_INTEGER_SIZE and R_XDR_DOUBLE_SIZE. I've added a check in rgdal
to ensure that type sizes match up.

THK