[PATCH] ldb: Use deterministic order of dict for tests

[Lukas Slebodnik]

On (21/01/19 14:01), Lukas Slebodnik via samba-technical wrote:
>On (19/01/19 10:27), Douglas Bagnall via samba-technical wrote:
>>hi Lukas
>>
>>On 19/01/19 8:48 AM, Lukas Slebodnik via samba-technical wrote:
>>> ehlo,
>>> 
>>> Unit test failed for me in fedora on s390x
>>> https://kojipkgs.fedoraproject.org//work/tasks/6615/32106615/build.log
>>> https://kojipkgs.fedoraproject.org//work/tasks/7969/32107969/build.log
>>> 
>>> But there is also a reasonable reproducer on x86_64
>>> 
>>> sh$ cat > reproducer.py <<EOF
>>> import ldb
>>> msg = ldb.Message()
>>> msg.dn = ldb.Dn(ldb.Ldb(), "dc=foo29")
>>> msg["dc"] = b"foo"
>>> print(repr(msg))
>>> EOF
>>> 
>>> sh$ PYTHONHASHSEED=2 python2 reproducer.py
>>> Message({'dc': MessageElement(['foo']), 'dn': Dn('dc=foo29')})
>>> 
>>> sh$ PYTHONHASHSEED=1 python2 reproducer.py
>>> Message({'dn': Dn('dc=foo29'), 'dc': MessageElement(['foo'])})
>>> 
>>> sh$  for i in {1..10}; do PYTHONHASHSEED=random python2
>>> reproducer.py; done
>>> Message({'dc': MessageElement(['foo']), 'dn': Dn('dc=foo29')})
>>> Message({'dc': MessageElement(['foo']), 'dn': Dn('dc=foo29')})
>>> Message({'dc': MessageElement(['foo']), 'dn': Dn('dc=foo29')})
>>> Message({'dn': Dn('dc=foo29'), 'dc': MessageElement(['foo'])})
>>> Message({'dc': MessageElement(['foo']), 'dn': Dn('dc=foo29')})
>>> Message({'dc': MessageElement(['foo']), 'dn': Dn('dc=foo29')})
>>> Message({'dc': MessageElement(['foo']), 'dn': Dn('dc=foo29')})
>>> Message({'dc': MessageElement(['foo']), 'dn': Dn('dc=foo29')})
>>> Message({'dn': Dn('dc=foo29'), 'dc': MessageElement(['foo'])})
>>> Message({'dc': MessageElement(['foo']), 'dn': Dn('dc=foo29')})
>>> 
>>> I was thinking about fixing it in pyldb.c but IMHO it does not worth
>>> to spend time with fixing it in C in case of trivial workaround when
>>> executing tests.
>>
>>yep. However in lib/ldb/Makefile (and other Makefiles) we have:
>>
>>WAF=PYTHONHASHSEED=1 WAF_MAKE=1 $(WAF_BINARY)
>>
>>[...]
>>
>>test:
>>        $(WAF) test $(TEST_OPTIONS)
>>
>>
>>Using, as you can see, "1" for the seed (it is there in the s390x
>>build logs). Evidently that doesn't fall through to the underlying
>>tests, at least not in all cases. But maybe sometimes it does.
>>
>>Which leads me to the two things I don't like so much about this patch:
>>

I spent more time debugging it on s390x and I can say that there is not any
issue with passing env PYTHONHASHSEED to the test.

The problem is with the value of env PYTHONHASHSEED.

It deterministically fails with the value 1.

So is there any reason why you insist on the value 1.
IMHO value 0 for PYTHONHASHSEED is perfectly valid and works on all
architectures in fedora
https://koji.fedoraproject.org/koji/buildinfo?buildID=1180702

I can send a patch to change all values from 1 -> 0 if there are not any
objection.

LS