On 14 December 2016 at 15:59, Andreas Tille wrote:
| Hi Christian,
|
| thanks a lot for your extensive analysis about of the stack problem. I
| admit I have no idea why this large stack is needed on those
| architectures with stable kernel. I also have no idea why everything
| went fine with treescape version 1.10.17. Since I personally fell
| totally clueless I'm forwarding this upstream and also CC Dirk
| Eddelbuettel who is known for his insight and good contact to the R
| community. May be somebody has a better clue rather than drastically
| increasing the stack size on those failed architectures.
One quick thought: does it die in _compilation_ which we have seen with other
(C++-heavy) packages? I know that this helps at times:
export CXX=g++ --param ggc-min-expand=20 -g0
Otherwise if it fails _after_ compilation we may be able to get by turning
some default aspects of R CMD INSTALL off:
--no-byte-compile do not byte-compile R code
--no-test-load skip test of loading installed package
But that is just guessing on my part and we'd have to test the package.
Dirk (at work)
| Thanks again
|
| Andreas.
|
| On Wed, Dec 14, 2016 at 03:37:27PM +0100, Christian Seiler wrote:
| > Hi again,
| >
| > On 12/14/2016 03:00 PM, Christian Seiler wrote:
| > > If I had to guess what was going on in the backtrace, I'd suspect
| > > an infinite recursion in R code, which translates to infinite
| > > recursion of the underlying C code. But I'm really not sure here.
| >
| > Interestingly enough, my initial guess was wrong.
| >
| > It's not an infinite recursion, it's just a very, very deep
| > recursion, using a LOT of stack. If I increase the stack size
| > limit by to 200 MB, then the package builds successfully,
| > I tried that in a loop 25 times.
| >
| > However, with an earlier attempt at 160 MB stack size limit,
| > it worked most of the time, but not always, I did get the
| > same error once, so the amount of stack space required does
| > not appear to be the same when calling the program multiple
| > times. (With 160 MB I tried around 15 times, and once the
| > 160 MB limit was insufficient.)
| >
| > It might even be in rare cases that the 200 MB limit is not
| > enough and a build could fail spuriously even with that.
| >
| > > Why that only appears to occur on 32bit LE architectures with
| > > stable kernels (and works fine with unstable kernels on the same
| > > architecture, and even with the stable kernel on 64bit both LE
| > > and BE, as well as on 32bit BE) I also have no clue.
| >
| > And this is still beyond me, because the default stack size
| > limit of 8 MB is more than sufficient on e.g. amd64, where
| > pointers are twice as large, so the amount of stack frames
| > that fit in that limit there is actually smaller.
| >
| > So it appears you can work around this bug by manually
| > setting an artificially high stack size limit during the
| > build, but there is still an underlying problem there that
| > causes the stack usage to be drastically higher on
| > 32bit LE platforms with kernel 3.16, that doesn't appear
| > on the same platforms with a newer kernel.
| >
| > Anyway, to work around this for now, you can replace your
| > dh_auto_install line (that is passed to the xvfb call)
| > with the following command:
| >
| > /bin/sh -c "ulimit -S -s 200000 ; exec dh_auto_install"
| >
| > Just tried it, sbuild built the package successfully on
| > i386. I haven't tried armhf, but I suspect the result will
| > be the same.
| >
| > But the underlying problem should also be fixed: a stack
| > size that is 25 times higher than usual is worrisome,
| > especially with the standard limit being plenty sufficient
| > on platforms with larger pointer sizes. You might have to
| > ask upstream and/or the R community for advice though. (Maybe
| > see what R function specifically does this deep recursion,
| > and fix that function to be a lot shallower. I don't know
| > how to get that information from a gdb backtrace though, as
| > I don't know the internals of R.)
| >
| > Hope that helps.
| >
| > Regards,
| > Christian
| >
|
| --
| http://fam-tille.de
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
