division by zero in winword

[Robbert Xerox]

Hi, in quite a few programs i can not browse the
filesystem when opening a "listbox"; to be more clear:
for example when i do in winword Open and the listbox
appears, and i try to open the pull down menu winword
just quits(without an error message in wine).  In
another program like "Camel join" it quits as soon as
i go up to the level of "my computer" with a message
"division by zero in Volme_ReadFATSuperblock. I was
able to
track the problem down to the following lines in
volume.c (starting from line 502)

nsect -= GETWORD(buff, 0x0e) + buff[0x10] * sz +
            (GETWORD(buff, 0x11) * 32 + (GETWORD(buff,
0x0b) - 1)) / GETWORD(buff, 0x0b);
        nclust = nsect / buff[0x0d];

when i change  these into this:

nsect -= GETWORD(buff, 0x0e) + buff[0x10] * sz +
            (GETWORD(buff, 0x11) * 32 + (GETWORD(buff,
0x0b) - 1)) / (GETWORD(buff, 0x0b)-1);
        nclust = nsect / (buff[0x0d]+1);

i can (obviously) avoid the division by zero and
everything (winword and camel join) just works fine.
I'm not a programmer, so this solution obviously
sucks, so my question is: how can this error be fixed,
and do more people encounter this problem.

PS i'm using the august version of wine, and in the
april version this whole problem didn't show up!
everything just worked fine there.

Thanks in advance, Robbert

___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

[Joris Huizer]

Robbert Xerox wrote:
> Hi, in quite a few programs i can not browse the
> filesystem when opening a "listbox"; to be more clear:
> for example when i do in winword Open and the listbox
> appears, and i try to open the pull down menu winword
> just quits(without an error message in wine).  In
> another program like "Camel join" it quits as soon as
> i go up to the level of "my computer" with a message
> "division by zero in Volme_ReadFATSuperblock. I was
> able to
> track the problem down to the following lines in
> volume.c (starting from line 502)
>   nsect -= GETWORD(buff, 0x0e) + buff[0x10] * sz +
>         (GETWORD(buff, 0x11) * 32 + (GETWORD(buff,
>
> 0x0b) - 1)) / GETWORD(buff, 0x0b);
>         nclust = nsect / buff[0x0d];

if (GETWORD(buff, 0x0b) == 0)
{
     /* what to do about this?? */
}
else
{
     nsect -= GETWORD(buff, 0x0e) + buff[0x10] * sz +
             (GETWORD(buff, 0x11) * 32 + (GETWORD(buff,
              0x0b) - 1)) / GETWORD(buff, 0x0b);
     if (buff[0x0d] == 0)
     {
         /* what to do about this one?? */
     }
     else
     {
         nclust = nsect / buff[0x0d];
     }
}

Now, how come those values become zero? I don't know, so I can't fill in 
the missing stuff there

HTH,

Joris

[Vincent Béron]

Le mer 22/09/2004 à 15:39, Joris Huizer a écrit :
> Robbert Xerox wrote:
> > Hi, in quite a few programs i can not browse the
> > filesystem when opening a "listbox"; to be more clear:
> > for example when i do in winword Open and the listbox
> > appears, and i try to open the pull down menu winword
> > just quits(without an error message in wine).  In
> > another program like "Camel join" it quits as soon as
> > i go up to the level of "my computer" with a message
> > "division by zero in Volme_ReadFATSuperblock. I was
> > able to
> > track the problem down to the following lines in
> > volume.c (starting from line 502)
> >   nsect -= GETWORD(buff, 0x0e) + buff[0x10] * sz +
> >         (GETWORD(buff, 0x11) * 32 + (GETWORD(buff,
> >
> > 0x0b) - 1)) / GETWORD(buff, 0x0b);
> >         nclust = nsect / buff[0x0d];
>
> if (GETWORD(buff, 0x0b) == 0)
> {
>      /* what to do about this?? */
> }
> else
> {
>      nsect -= GETWORD(buff, 0x0e) + buff[0x10] * sz +
>              (GETWORD(buff, 0x11) * 32 + (GETWORD(buff,
>               0x0b) - 1)) / GETWORD(buff, 0x0b);
>      if (buff[0x0d] == 0)
>      {
>          /* what to do about this one?? */
>      }
>      else
>      {
>          nclust = nsect / buff[0x0d];
>      }
> }
>
> Now, how come those values become zero? I don't know, so I can't fill in 
> the missing stuff there
> From an IRC session with the original user (or at least somebody pasting

the exact same question), he was using Wine as root, with a z: drive
pointing to /. The permissions on his / partition allowed Wine to read
the device directly.

Running Wine as a normal user fixed it for him.

Now onto what I think is a proper fix:
Note that the following check
    if (buff[0] == 0xE9 || (buff[0] == 0xEB && buff[2] == 0x90))
did pass before the above code snippet is executed, and doesn't
discriminate against other types of bootloaders (as that's what's
usually in the first sector, even a FAT). Indeed, my /dev/hde (boot
drive) MBR does pass the test as grub is installed in /dev/hde. If grub
had been installed in /dev/hde2 (/boot), the test would fail, but if I
had a single partition for /boot and / (rest of tree doesn't matter),
and installed grub in it's first sector rather than MBR, it'd pass.

So maybe we should actually check for the FAT signature at buff[0x36] or
buff[0x52] first, and then do the calculations if we actually do find
one of them.

Changelog:
Make sure we're really looking at a FAT before doing some calculations
based on the contents of the first sector of a partition.

Vincent

[Alexandre Julliard]

Vincent Béron  writes:
> So maybe we should actually check for the FAT signature at buff[0x36] or
> buff[0x52] first, and then do the calculations if we actually do find
> one of them.
>
> Changelog:
> Make sure we're really looking at a FAT before doing some calculations
> based on the contents of the first sector of a partition.

That doesn't solve the real issue, a FAT signature is not a guarantee
that the rest of the block is valid, so we still need to check these
values against zero. The code should not crash no matter what garbage
the block contains.