Re: Assertion failed when building r-base on Aranym
Hi Finn!
Thanks for your comment!
On 12/04/2016 12:50 AM, Finn Thain wrote:
> When I googled that assertion failure, I got the impression that whilst
> the assertion is in glibc code, the bug usually isn't. The assertion gets
> triggered when glibc data structures get clobbered by a program that
> overflows an allocated block etc.
>
>> /bin/bash: line 1: 17541 Done echo
>> "tools:::data2LazyLoadDB(\"datasets\", compress=3)"
>> 17542 Aborted | R_DEFAULT_PACKAGES=NULL LC_ALL=C ../../../bin/R --vanilla --slave > /dev/null
>> Makefile:21: recipe for target 'all' failed
>>
>
> ... which leads me to think the bug is probably in this R binary.
Sounds reasonable, however, there is one problem with that theory. As I have
already mentioned, the problem also affects a version of r-base which is
known to be good as it previously built fine:
good: https://buildd.debian.org/status/fetch.php?pkg=r-base&arch=m68k&ver=3.2.2-1&stamp=1445983541
bad: https://buildd.debian.org/status/fetch.php?pkg=r-base&arch=m68k&ver=3.2.2-1&stamp=1480420610
Same version. Different default gcc (gcc-5 vs. gcc-6), different glibc (2.19 vs. 2.24),
different default compiler options (dpkg is injecting -fPIE. Kernel is identical.
I'm currently testing whether this is a result of dpkg defaulting the build to -fPIE.
> I suppose you or Andreas could try this binary on a system with a
> known-good glibc if you wanted to eliminate glibc as a possible cause.
Downgrading glibc directly did not work due to Perl. But I could work
around this LD_PRELOAD. I will try that later.
> Are there debugging tools or malloc implementations on m68k that could
> isolate an out-of-bounds access to heap memory?
No idea. Is there?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: