Date: Tue, 7 Oct 2014 22:17:03 +0200 From: Antoine Brodin <antoine@freebsd.org> To: Matthias Andree <mandree@freebsd.org> Cc: freebsd-toolchain@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: 11-CURRENT redports builders miscompiling? Message-ID: <CAALwa8nc=wCBKCkcUQu9LOfBqr5NH8XqKxpTXhUDwGZBeQgEUA@mail.gmail.com> In-Reply-To: <543443CE.6000900@FreeBSD.org> References: <201410071915.s97JFrQo061043@svn.freebsd.org> <54343E60.7050208@FreeBSD.org> <CAALwa8k1EejjEk_HFFXVvLGyg4d69UWZoBhHkvydMf5yLe-FCA@mail.gmail.com> <543443CE.6000900@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 7, 2014 at 9:49 PM, Matthias Andree <mandree@freebsd.org> wrote: > Am 07.10.2014 um 21:32 schrieb Antoine Brodin: >> On Tue, Oct 7, 2014 at 9:26 PM, Matthias Andree <mandree@freebsd.org> wrote: >>> Greetings, >>> >>> I have just updated sysutils/e2fsprogs and its slave ports(*), and test >>> drove them on redports. The self-test suite is failing on 11-CURRENT >>> i386 and amd64, but not on 10 or older releases. >>> >>> 11-amd64: https://redports.org/buildarchive/20141007190638-31576 >>> 11-i386: https://redports.org/buildarchive/20141007185700-4151 >>> >>> I am now wondering >>> - if there are issues with the toolchain on 11 that causes >>> miscompilation, or >>> - whether 11 is misbehaving on redports, or >>> - if e2fsprogs has code bugs that don't show on older toolchains. >> >> Hi, >> >> e2fsprogs version 1.42.10 tests were succeeding in a jail with a world >> from r272576 (1.5 day old) >> >> http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p370135_s272576/logs/e2fsprogs-1.42.10.log >> >> (this is poudriere, not tinderbox) > > Hi Antoine, > > merci for that. > > There are probably multiple changes, so if someone else can take the > newer 1.42.12 for a test on 11-current, either on a naked system or with > poudriere, that will be appreciated. What I find odd is that the > redports logs also show output deviations from expected, for instance, > here: > >> ==> /work/a/ports/sysutils/e2fsprogs/work/e2fsprogs-1.42.12/tests/r_resize_inode.failed <== >> --- r_resize_inode/expect 2014-08-25 03:08:16.000000000 +0000 >> +++ r_resize_inode.log 2014-10-07 19:10:00.000000000 +0000 >> @@ -1,7 +1,7 @@ >> mke2fs -q -F -O resize_inode -o Linux -b 1024 -g 1024 test.img 16384 >> resize2fs test.img 65536 >> Resizing the filesystem on test.img to 65536 (1k) blocks. >> -The filesystem on test.img is now 65536 (1k) blocks long. >> +The filesystem on test.img is now 65536 (1480342k) blocks long. >> >> Pass 1: Checking inodes, blocks, and sizes >> Pass 2: Checking directory structure > > The block size is bogus, and this happens on i386 and amd64 so is not > /obviously/ an issue of sizeof(long) or thereabouts. So, the test fail on head, but if you look carefully, 1480342*1024 = 0x5a5a... which looks like malloc junk. But when I turn off malloc debugging ( ln -s 'abort:false,junk:false' /etc/malloc.conf ) the tests succeed. So it looks like a bug in e2fsprogs. Cheers, Antoine
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAALwa8nc=wCBKCkcUQu9LOfBqr5NH8XqKxpTXhUDwGZBeQgEUA>