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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
