On Sat, 3 Dec 2016, John Paul Adrian Glaubitz wrote: > On 11/29/2016 12:39 AM, Andreas Schwab wrote: > > On Nov 29 2016, John Paul Adrian Glaubitz > > <[email protected]> wrote: > > > >> Are there any m68k-specific patches or build flags which might be > >> missing in Debian? If possible, could you share your SRPM? > > > > It's a bog-standard configure/make/install. Make sure your glibc > > wasn't miscompiled by the broken qemu. > > Ok, I have recompiled glibc on Aranym and tried building r-base with > that version. The problem is still occurring: > > R: malloc.c:2403: sysmalloc: Assertion `(old_top == initial_top (av) && > old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse > (old_top) && ((unsigned long) old_end & (pages ize - 1)) == 0)' failed.
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. 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. Are there debugging tools or malloc implementations on m68k that could isolate an out-of-bounds access to heap memory? -- > The last known successful build on Aranym was with Debian's > libc6_2.19-16 package with r-base 3.2.2 [1]. Will downgrad glibc to this > version now and try again. > > Adrian > > > [1] > > https://buildd.debian.org/status/fetch.php?pkg=r-base&arch=m68k&ver=3.2.2-1&stamp=1445983541 > >

