Re: Reproducible builds

> Od: Marcus Meissner <marcus(a)jet.franken.de>
>
> CC: <stefandoesinger(a)gmail.com, wine-devel(a)winehq.org>
> On Sun, Feb 19, 2017 at 05:36:30PM +0100, wylda(a)volny.cz wrote:
> > > Od: Stefan Dösinger <stefandoesinger(a)gmail.com>
> > >
> > > Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz:
> > > > Anyway, there are 7 files out of 2750 which _always_ pickup some random
> > > > value and use that consistently. Why are these libraries built
> > > > inconsitently? Is that intentional? An example is attached.
> > >
> > > Have you looked at the .o files of those libraries? Finding the .c file
> > > that introduces the difference might give some hints to pin down the
> > > problem.
> >
> > Thanks. These "random" value come from:
> >
> > * olepro_t.res
> >  * std_ole_v2_t.res
> >  * wuapi_tlb_t.res
> >
> > Anyway, all the other folders also have *.res files. Can these 3 be "fixed"
> > so that they behave like the rest of dll-folders? Or can i pass some kind
> > of parameter or switch?
>
> std_ole_v2_t.res always comes out the same for me, in 32 and 64bit builds
> when I set WIDL_TIME_OVERRIDE="0".
>
> Same for olepro_t.res
>
> (current git state)

When i do:

export WIDL_TIME_OVERRIDE="0"
rm dlls/olepro32/olepro_t.res
make -k dlls/olepro32
md5sum -b dlls/olepro32/olepro_t.res

then i always get different MD5 checksum.

Marcus, could you send me your dlls/olepro32/Makefile please?
What is your distro?

Reproducible builds

[Marcus Meissner]

On Sun, Feb 19, 2017 at 07:46:43PM +0100, wylda(a)volny.cz wrote:
> > Od: Marcus Meissner <marcus(a)jet.franken.de>
> >
> > CC: <stefandoesinger(a)gmail.com, wine-devel(a)winehq.org>
> > On Sun, Feb 19, 2017 at 05:36:30PM +0100, wylda(a)volny.cz wrote:
> > > > Od: Stefan Dösinger <stefandoesinger(a)gmail.com>
> > > >
> > > > Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz:
> > > > > Anyway, there are 7 files out of 2750 which _always_ pickup some random
> > > > > value and use that consistently. Why are these libraries built
> > > > > inconsitently? Is that intentional? An example is attached.
> > > >
> > > > Have you looked at the .o files of those libraries? Finding the .c file
> > > > that introduces the difference might give some hints to pin down the
> > > > problem.
> > >
> > > Thanks. These "random" value come from:
> > >
> > > * olepro_t.res
> > >  * std_ole_v2_t.res
> > >  * wuapi_tlb_t.res
> > >
> > > Anyway, all the other folders also have *.res files. Can these 3 be "fixed"
> > > so that they behave like the rest of dll-folders? Or can i pass some kind
> > > of parameter or switch?
> >
> > std_ole_v2_t.res always comes out the same for me, in 32 and 64bit builds
> > when I set WIDL_TIME_OVERRIDE="0".
> >
> > Same for olepro_t.res
> >
> > (current git state)
>
> When i do:
>
> export WIDL_TIME_OVERRIDE="0"
> rm dlls/olepro32/olepro_t.res
> make -k dlls/olepro32
> md5sum -b dlls/olepro32/olepro_t.res
>
> then i always get different MD5 checksum.
>
> Marcus, could you send me your dlls/olepro32/Makefile please?
> What is your distro?

I tried above for both 32bit and 64bit directories, always gives the same md5 in those.

64bit:
0235f984f3f9f4c781e4e92e5ae7299f *dlls/olepro32/olepro_t.res
32bit:
106679b36afba236fc28484e69f672f7 *dlls/olepro32/olepro_t.res

openSUSE Tumbleweed, with currently gcc 6.3.1+r245113, binutils-2.27, flex-2.6.1, bison-3.0.4


Your debug diff showed a single value fluctuating in multiple places, but its not clear which offset this
was at. It could be either uninitialized memory or some hash value or so.
valgrind showing anything?

Ciao, Marcus

Reproducible builds

[André Hentschel]

Am 19.02.2017 um 22:32 schrieb Marcus Meissner:
> On Sun, Feb 19, 2017 at 07:46:43PM +0100, wylda(a)volny.cz wrote:
> > > Od: Marcus Meissner <marcus(a)jet.franken.de>
> > >
> > > CC: <stefandoesinger(a)gmail.com, wine-devel(a)winehq.org>
> > > On Sun, Feb 19, 2017 at 05:36:30PM +0100, wylda(a)volny.cz wrote:
> > > > > Od: Stefan Dösinger <stefandoesinger(a)gmail.com>
> > > > >
> > > > > Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz:
> > > > > > Anyway, there are 7 files out of 2750 which _always_ pickup some random
> > > > > > value and use that consistently. Why are these libraries built
> > > > > > inconsitently? Is that intentional? An example is attached.
> > > > >
> > > > > Have you looked at the .o files of those libraries? Finding the .c file
> > > > > that introduces the difference might give some hints to pin down the
> > > > > problem.
> > > >
> > > > Thanks. These "random" value come from:
> > > >
> > > > * olepro_t.res
> > > >  * std_ole_v2_t.res
> > > >  * wuapi_tlb_t.res
> > > >
> > > > Anyway, all the other folders also have *.res files. Can these 3 be "fixed"
> > > > so that they behave like the rest of dll-folders? Or can i pass some kind
> > > > of parameter or switch?
> > >
> > > std_ole_v2_t.res always comes out the same for me, in 32 and 64bit builds
> > > when I set WIDL_TIME_OVERRIDE="0".
> > >
> > > Same for olepro_t.res
> > >
> > > (current git state)
> >
> > When i do:
> >
> > export WIDL_TIME_OVERRIDE="0"
> > rm dlls/olepro32/olepro_t.res
> > make -k dlls/olepro32
> > md5sum -b dlls/olepro32/olepro_t.res
> >
> > then i always get different MD5 checksum.
> >
> > Marcus, could you send me your dlls/olepro32/Makefile please?
> > What is your distro?
>
> I tried above for both 32bit and 64bit directories, always gives the same md5 in those.
>
> 64bit:
> 0235f984f3f9f4c781e4e92e5ae7299f *dlls/olepro32/olepro_t.res
> 32bit:
> 106679b36afba236fc28484e69f672f7 *dlls/olepro32/olepro_t.res
>
> openSUSE Tumbleweed, with currently gcc 6.3.1+r245113, binutils-2.27, flex-2.6.1, bison-3.0.4
>
> Your debug diff showed a single value fluctuating in multiple places, but its not clear which offset this
> was at. It could be either uninitialized memory or some hash value or so.
> valgrind showing anything?
>
> Ciao, Marcus

I can reproduce the bug with the instructions above
Linux Mint 18.1, gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4), binutils 2.26.1, flex 2.6, biso 3.0.4
the first bad value is at offset 269h
Which is datatype2 from MSFT_TypeInfoBase

So initializing datatype2 in add_typedef_typeinfo or the following patch fixes the problem for me:

diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c
index 137bb2d..7904e45 100644
--- a/tools/widl/write_msft.c
+++ b/tools/widl/write_msft.c
@@ -798,6 +798,7 @@ static int encode_type(
     if (!alignment) alignment = &scratch;
     if (!decoded_size) decoded_size = &scratch;
 
+    *decoded_size = 0;
 
     switch (vt) {
     case VT_I1:

Reproducible builds

[Huw Davies]

On 19 Feb 2017, at 23:28, André Hentschel <nerv(a)dawncrow.de> wrote:
> I can reproduce the bug with the instructions above
> Linux Mint 18.1, gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4), binutils 2.26.1, flex 2.6, biso 3.0.4
> the first bad value is at offset 269h
> Which is datatype2 from MSFT_TypeInfoBase
>
> So initializing datatype2 in add_typedef_typeinfo or the following patch fixes the problem for me:
>
> diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c
> index 137bb2d..7904e45 100644
> --- a/tools/widl/write_msft.c
> +++ b/tools/widl/write_msft.c
> @@ -798,6 +798,7 @@ static int encode_type(
>     if (!alignment) alignment = &scratch;
>     if (!decoded_size) decoded_size = &scratch;
>
> +    *decoded_size = 0;
>
> switch (vt) {
>     case VT_I1:

This looks good to me, please send this in - the size in datatype2
should apparently be zero unless the type is complex.

Thanks for tracking this down.

Huw.