[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Assertion failed when building r-base on Aranym



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 
> > <glaubitz@physik.fu-berlin.de> 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
> 
> 


Reply to: