[R-sig-Geo] followup on rgdal - invalid alignment error

Fri Sep 8 23:16:55 CEST 2006

On Fri, 8 Sep 2006, Tim Keitt wrote:

> On 9/8/06, Roger Bivand <Roger.Bivand at nhh.no> wrote:
> > On Fri, 8 Sep 2006, Tim Keitt wrote:
> >
> > > 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.)
> >
> > (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.
> 
> 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.

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

> 
> >
> > 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?
> 
> Nope. Shouldn't be a problem.
> 
> THK
> 
> >
> > Roger
> >
> > >
> > > 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:
> > > > On Fri, 8 Sep 2006, Scott W Mitchell wrote:
> > > >
> > > > > 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.
> > > >
> > > > 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.
> > > >
> > > > >
> > > > > It gets through translating the data set and the image command, but
> > > > > then on summary() I get:
> > > >
> > > > 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
> > > >
> > > > >
> > > > > 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
> > > > >
> > > > > _______________________________________________
> > > > > R-sig-Geo mailing list
> > > > > R-sig-Geo at stat.math.ethz.ch
> > > > > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> > > > >
> > > >
> > > > --
> > > > Roger Bivand
> > > > Economic Geography Section, Department of Economics, Norwegian School of
> > > > Economics and Business Administration, Helleveien 30, N-5045 Bergen,
> > > > Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
> > > > e-mail: Roger.Bivand at nhh.no
> > > >
> > > > _______________________________________________
> > > > R-sig-Geo mailing list
> > > > R-sig-Geo at stat.math.ethz.ch
> > > > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> > > >
> > >
> > >
> > >
> >
> > --
> > Roger Bivand
> > Economic Geography Section, Department of Economics, Norwegian School of
> > Economics and Business Administration, Helleveien 30, N-5045 Bergen,
> > Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
> > e-mail: Roger.Bivand at nhh.no
> >
> >
> >
> 
> 
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no