Re: port-mac68k/51783: fsck crashes with a "floating point excepton" error message.

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR port-mac68k/51783; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-mac68k/51783: fsck crashes with a "floating point excepton" error message.
Date: Thu, 19 Jan 2017 19:22:03 +0000 (UTC)

 bjarne.backstrom%hjomail.se@localhost (=?utf-8?B?Qmphcm5lIELDpGNrc3Ryw7Zt?=) writes:
 
 >    Ok, I sent a copy of  fsck_ffs core to Martin Husemann, but didn=E2=80=99=
 > t send it to the list because the list seems to automatically expand =
 > compressed file attachments, and this one will expand to 1.7 MB or so. =
 > If anyone wants to have a copy, just let me know.
 
 Just saw a similar issue on NetBSD/amiga.
 
 The statically linked fsck_ffs from /rescue seems to work, also
 fsck_ffs from current.
 
 The faulty fsck_ffs gets the SIGFPE in:
 
 Program received signal SIGFPE, Arithmetic exception.
 0x0e047f32 in __udivdi3 () from /lib/libutil.so.7
 (gdb) bt
 #0  0x0e047f32 in __udivdi3 () from /lib/libutil.so.7
 #1  0x00006a60 in iblock ()
 #2  0x00007362 in ckinode ()
 #3  0x0000afe4 in checkinode ()
 #4  0x0000b9c0 in pass1 ()
 #5  0x000099cc in checkfilesys.part ()
 #6  0x00019520 in main ()
 
 This is the place in iblock():
 
         if (howmany(isize, sizepb) > (size_t)FFS_NINDIR(sblock))
                 nif = FFS_NINDIR(sblock);
         else
                 nif = howmany(isize, sizepb);
 
 where the first howmany() macro calls __udivdi3
 
 0x6a5a <iblock+214>: jsr 0x391c <__udivdi3@plt>
 
 0x391c <__udivdi3@plt>: jmp %pc@(0x201b0 <__udivdi3%got.plt@localhost>)@(00000000)
 
 0x201b0 <__udivdi3%got.plt@localhost>:    0x0e047efc
 
 (gdb) x/20i 0x0e047efc
    0xe047efc <__udivdi3>:       linkw %fp,#0
    0xe047f00 <__udivdi3+4>:     moveml %d2-%d7,%sp@-
    0xe047f04 <__udivdi3+8>:     movel %fp@(8),%d0
    0xe047f08 <__udivdi3+12>:    movel %fp@(12),%d1
    0xe047f0c <__udivdi3+16>:    movel %fp@(16),%d3
    0xe047f10 <__udivdi3+20>:    movel %fp@(20),%d2
    0xe047f14 <__udivdi3+24>:    movel %d2,%d4
    0xe047f16 <__udivdi3+26>:    tstl %d3
    0xe047f18 <__udivdi3+28>:    bnes 0xe047f3e <__udivdi3+66>
    0xe047f1a <__udivdi3+30>:    cmpl %d2,%d0
    0xe047f1c <__udivdi3+32>:    bccs 0xe047f26 <__udivdi3+42>
    0xe047f1e <__udivdi3+34>:    divul %d2,%d0,%d1
    0xe047f22 <__udivdi3+38>:    clrl %d0
    0xe047f24 <__udivdi3+40>:    bras 0xe047f9a <__udivdi3+158>
    0xe047f26 <__udivdi3+42>:    tstl %d2
    0xe047f28 <__udivdi3+44>:    bnes 0xe047f32 <__udivdi3+54>
    0xe047f2a <__udivdi3+46>:    moveq #1,%d4
    0xe047f2c <__udivdi3+48>:    clrl %d3
    0xe047f2e <__udivdi3+50>:    divull %d3,%d4,%d4
 => 0xe047f32 <__udivdi3+54>:    clrl %d2
 ...
 
 This is the beginning of the __udivdi3 version provided by libgcc2.c.
 
 d3 is zero. This is the code in __udivdi3 that causes a SIGFPE when
 called with a zero divisor (d3 == high 32bit, d2 == low 32bit),
 which is the sizepb value above.
 
 d2             0x0      0
 d3             0x0      0
 
 or all values from the stack.
 
 (gdb) x/4x $fp+8
 0x1dfed54c:     0x00000000      0x02e10946      0x00000000      0x00000000
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."