[R-pkg-devel] R CMD check crash for Ubuntu 14.04 R-3.2.1 only
charlie at stat.umn.edu
Sat Jul 4 17:20:59 CEST 2015
I should add a more direct question. When a crash occurs ONLY when running
R CMD check, how does one debug that? Usually one would say that R CMD
is the answer. But it only segfaults when --use-vagrind is not used. So
somehow we have to debug R CMD check itself. How?
On Sat, Jul 4, 2015 at 10:15 AM, Charles Geyer <charlie at stat.umn.edu> wrote:
> The diff for bar.Rout is OK. The solution is the same (the two matrices
> have the same rows and so determine the same convex polyhedron). Why it
> picks different orders of rows on different machines, I have no idea.
> I also saw the pages of warnings from gcc -W -Wall -Wextra but they are
> all about unused variables and unused arguments of functions. AFAIK these
> are not real problems.
> I should say that I did not write most of the code. This package is an R
> interface to the computational geometry provided by cddlib, which is not
> something linux distributions package. So in order to avoid hassle, I just
> included the cddlib code (which is GPL) in the src directory and added its
> author Komei Fukuda to the authors of the package.
> AFAIK this code is very high quality from a numerical analysis standpoint,
> however much it may fall below the coding standards of most C coders.
> Anyway it is the only free software computational geometry code I know
> about, so it is the only game in town unless statisticians want to just say
> "we cannot deal with problems like that".
> This code may actually segfault somewhere, but we haven't seen it in
> practice unless this is its fault (rather than the 32 bit R-3.2.1 build for
> Ubuntu 14.04). We still don't have a way to tell which to blame.
> I am trying to follow the debugging rules (http://debuggingrules.com/)
> the most important here being "divide and conquer". Until we know where
> the crash occurs, we are just clueless.
> On Sat, Jul 4, 2015 at 3:35 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
>> I took a look based on your tar ball. When I use the normal 'loud'
>> setting I
>> default to for g++ (ie -pedantic -Wall) or clang++ I get more than a page
>> full of errors. I just tried it using the UBSAN-via-clang instrumented R
>> provide via a docker container (and for which I showed usage during the
>> 'rocker: Docker on R' tutorial preceding useR! -- slides now on my
>> presentation page). It also does not segfault, but it shows a test
>> Running ‘bar.R’
>> Comparing ‘bar.Rout’ to ‘bar.Rout.save’ ...8d7
>> < [1,] 0 1 0 1 0 0
>> < [2,] 0 1 1 0 0 0
>> < [3,] 0 1 0 0 1 0
>> < [4,] 0 1 0 0 0 1
>> > [1,] 0 1 0 0 0 1
>> > [2,] 0 1 0 0 1 0
>> > [3,] 0 1 0 1 0 0
>> > [4,] 0 1 1 0 0 0
>> Running ‘bug2.R’
>> Comparing ‘bug2.Rout’ to ‘bug2.Rout.save’ ...8d7
>> (You also seem to consistently differ in one newline which is just a
>> and not an error,)
>> So no free lunch yet. I fear you may have to minimize the package
>> to hopefully arrive at minimally reproducible example. So far you seem to
>> have a Heisenbug (https://en.wikipedia.org/wiki/Heisenbug)
>> Sorry I cannot offer more help.
>> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> Charles Geyer
> Professor, School of Statistics
> University of Minnesota
> charlie at stat.umn.edu
Professor, School of Statistics
University of Minnesota
charlie at stat.umn.edu
[[alternative HTML version deleted]]
More information about the R-package-devel