# for i in `seq 256`; do export MALLOC_PERTURB_=$i; .libs/lt-cve-2015-4491>/dev/null && echo $i: good || echo $i: bad; done 1: bad 2: good 3: good 4: bad 5: bad 6: good 7: good 8: good 9: good 10: bad 11: good 12: good 13: good 14: bad 15: good 16: good 17: good 18: good
Leads me to belief that the test is broken, and depends on the actuall memory to be in a consistent state after allocation. It seems that it has been recognised already that the test is borked, and it ends up skipping said test most of the time on s390x with OOM error. In my instance, it's getting OOM killed, rather than getting OOM error. Disabling MALLOC_PERTURB_ passes the test, which I've now done. This bug should be forwared upstream, for further investigation. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gdk-pixbuf in Ubuntu. https://bugs.launchpad.net/bugs/1519030 Title: cve-2015-4491 fails with MALLOC_CHECK_=2 and MALLOC_PERTURB_=$((${RANDOM:-256} % 256)), sometimes Status in gdk-pixbuf package in Ubuntu: New Bug description: cve-2015-4491 fails with MALLOC_CHECK_=2 and MALLOC_PERTURB_=$((${RANDOM:-256} % 256)), sometimes it's possibly being killed with OOM, so need to validate that first. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/1519030/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp