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