11-CURRENT redports builders miscompiling?

[Antoine Brodin]

On Tue, Oct 7, 2014 at 9:49 PM, Matthias Andree <mandree at 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 at 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