[Debian-med-packaging] Bug#845753: Possible workaround

[Andreas Tille]

Hi,

On Wed, Dec 14, 2016 at 03:57:13PM -0600, Dirk Eddelbuettel wrote:
> |   RGL: unable to open X11 display
> | Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE
> | Error: segfault from C stack overflow
> | * removing '/home/christian/r-cran-treescape-1.10.18/debian/r-cran-treescape/usr/lib/R/site-library/treescape'
> | 
> | (Ignore the X warnings, they are irrelevant here, I'm too lazy to run
> | it in xvfb and it's in a VM without X.)
> 
> xvfb does not given you OpenGL. This wants X11 _and OpenGL_.

This was discussed before.  The output above is from a previous package
version where I simply forgot to actually use xvfb.  Since this error
of mine the package was build without RGL - thus the warning.  Later I
was using xvfb correctly including OpenGL (thanks to Gregor Hermann who
pointed me to the solution).  However, the segfault remained.
 
> Because of that, I think it would be worthwhile to check if it were to build
> without the need for rgl.

As said above this was the initial state (unintentionally) - or do you
have something else in mind?
 
> Else the '--no-test-load' added to the 'R CMD INSTALL' call should skip all
> that.  We would need a local copy of r-cran.mk, or just copy it and adjust.
> 
> Maybe Andreas can give you a hand?

Sorry, but I have no idea how since I'm totally clueless currently and
upstream also did not yet responded to this after the initial idea that
it might be some ape related issue was not helpful.  Do you in turn see
any chance to push this question to the right forum in the R community?

I do not think that hiding our eyes from a potential problem by simply
increasing the stack size to an insane value is a proper way to solve
the issue - but currently there is no better idea on the table.
 
> | btw., since the program uses a huge stack, but there is no system
> | call related stuff going on (and the package doesn't appear to
> | interface directly with the kernel anyway, it's much too high level
> | for that), and the problem persists for the given kernel over a lot
> | of very different architectures.
> 
> It sounds like a bug at the system level. R packages tend not to be that
> greedy at build or load.

I admit that it is the first time that I'm observing an issue like this
in lots of R packages I'm maintaining.  However, there must be some
deeper reason for the failure and I personally have no idea how to track
this down.  I'd welcome if you can propagate the issue or tell me the
right forum to bring this up.
 
Kind regards

     Andreas.

-- 
http://fam-tille.de