Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Dec 2016 13:14:33 +0100
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Jakub Palider <jpa@semihalf.com>
Cc:        Hans Petter Selasky <hps@selasky.org>, Colin Percival <cperciva@tarsnap.com>, freebsd-current@freebsd.org
Subject:   Re: clang/llvm 3.9.0 mysteriously zeroing variables?
Message-ID:  <8618D217-9DD6-4732-A1C1-D980C4FD3E9E@FreeBSD.org>
In-Reply-To: <CAL7QUyNeHiUANEtBzT1gGU9En_tOvy%2Bey5qGR9p_dLhWgsJsAw@mail.gmail.com>
References:  <01000158c7252f0c-6c3198b0-fbef-4a60-ade9-e3b91d9e83bd-000000@email.amazonses.com> <e0646eb8-d793-1ffb-bd12-febbce86a4f8@selasky.org> <78FB227F-3542-452F-9A16-4FB0E0E698AC@FreeBSD.org> <CAL7QUyNeHiUANEtBzT1gGU9En_tOvy%2Bey5qGR9p_dLhWgsJsAw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_6DE4CF03-636A-43C3-94CA-06B3B4B8B260
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

See here: =
https://lists.freebsd.org/pipermail/svn-src-head/2016-December/094657.html=

and here: =
https://lists.freebsd.org/pipermail/svn-src-head/2016-December/094695.html=


I committed a fix on Dec 14, and MFCd it on Dec 18.

-Dimitry

> On 20 Dec 2016, at 11:54, Jakub Palider <jpa@semihalf.com> wrote:
>=20
> Hi,
>=20
> do you still observe this behaviour? Which type of EC2 instances were =
affected?
> I tried to reproduce with kernel/tools from Dec 15 and did not manage =
to crash the machine.
>=20
> Jakub
>=20
> On Sun, Dec 4, 2016 at 5:38 PM, Dimitry Andric <dim@freebsd.org> =
wrote:
> On 04 Dec 2016, at 10:52, Hans Petter Selasky <hps@selasky.org> wrote:
> >
> > On 12/04/16 01:04, Colin Percival wrote:
> >> Starting with r309124 (when clang/llvm 3.9.0 was imported) I'm =
seeing EC2
> >> instances panic on boot with a division-by-zero error; the code in =
question
> >> is in blkfront.c, printing out the size of disks:
> >>
> >>>             device_printf(dev, "%juMB <%s> at %s",
> >>>                 (uintmax_t) sectors / (1048576 / sector_size),
> >>>                 device_get_desc(dev),
> >>>                 xenbus_get_node(dev));
> >>
> >> My first thought was that 'sector_size' must be either zero or very =
large...
> >> but no, when I add printf("sector_size =3D %ju\n", =
(uintmax_t)sector_size), it's
> >> entirely normal.  What's more, adding that printf makes the =
division-by-zero
> >> panic go away.
> >>
> >> I'd think I was just hallucinating, but earlier today I heard that =
a similarly
> >> "impossible" panic had been observed in the NFS client code when =
compiled with
> >> clang/llvm 3.9.0.
> >>
> >> So... is anyone else seeing unexpected panics or other odd =
behaviour starting
> >> after clang/llvm 3.9.0 was imported?
> >>
> >
> > Hi,
> >
> > Can you look at the code with "objdump -Dx --source" and see what is =
going on there? Might it be the "sector" variable is shadowed?
>=20
> I don't see anything in the generated code for the call that can cause
> this, except for sector_size really being zero, or the result of
> 1048576/sector_size being zero.
>=20
> On i386, you get this:
>=20
>         .loc    1 1349 19               # =
/usr/src/sys/dev/xen/blkfront/blkfront.c:1349:19
>         movl    -56(%ebp), %ecx         # -56(%rbp) =3D sectors
> .Ltmp1148:
>         #DEBUG_VALUE: xbd_connect:sectors <- %ECX
>         .loc    1 1349 38 is_stmt 0     # =
/usr/src/sys/dev/xen/blkfront/blkfront.c:1349:38
>         movl    $1048576, %eax          # imm =3D 0x100000
>         xorl    %edx, %edx
>         divl    -52(%ebp)               # -52(%ebp) =3D sector_size
>         movl    %eax, %edi
>         .loc    1 1349 27               # =
/usr/src/sys/dev/xen/blkfront/blkfront.c:1349:27
>         xorl    %edx, %edx
>         movl    %ecx, %eax
>         divl    %edi
>         movl    %eax, -32(%ebp)         # 4-byte Spill
>=20
> On amd64, it looks pretty similar:
>=20
>         .loc    1 1349 19               # =
/usr/src/sys/dev/xen/blkfront/blkfront.c:1349:19
>         movq    -112(%rbp), %rcx        # -112(%rbp) =3D sectors
> .Ltmp1128:
>         #DEBUG_VALUE: xbd_connect:sectors <- %RCX
>         .loc    1 1349 38 is_stmt 0     # =
/usr/src/sys/dev/xen/blkfront/blkfront.c:1349:38
>         movl    $1048576, %eax          # imm =3D 0x100000
>         xorl    %edx, %edx
>         divq    -88(%rbp)               # -88(%rbp) =3D sector_size
>         movq    %rax, %rsi
>         .loc    1 1349 27               # =
/usr/src/sys/dev/xen/blkfront/blkfront.c:1349:27
>         xorl    %edx, %edx
>         movq    %rcx, %rax
>         divq    %rsi
>         movq    %rax, %r15
>=20
> Colin, does it panic for you in the first or the second div?
>=20
> -Dimitry
>=20
>=20


--Apple-Mail=_6DE4CF03-636A-43C3-94CA-06B3B4B8B260
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.30

iEYEARECAAYFAlhZIK4ACgkQsF6jCi4glqNJqQCdEKmFHPiarjp/V+2UDozJ8RpE
4REAoNnyJoRpVKS5HRKLD4MVBZebXiK7
=Fq0Q
-----END PGP SIGNATURE-----

--Apple-Mail=_6DE4CF03-636A-43C3-94CA-06B3B4B8B260--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8618D217-9DD6-4732-A1C1-D980C4FD3E9E>