GNOME Bugzilla – Bug 755691
/bitmask/invert_range_hardcoded test fails
Last modified: 2015-09-28 06:59:03 UTC
One of the tests in Gtk+ 3.18.0 testsuite on fails for me on i686: ERROR:/build/gtk+3.0-Bpo9Xn/gtk+3.0-3.18.0/./testsuite/gtk/bitmask.c:370:test_invert_range_hardcoded: bitmask (0) != ref (11111111111111111111111111111111) /bitmask/intersect_hardcoded: OK /bitmask/subtract_hardcoded: OK /bitmask/invert_range: OK /bitmask/invert_range_hardcoded: FAIL gdb tells that it fails when t = l = 0, r = 3.
This happens because _gtk_bitmask_invert_range (0x1, 0, 32) returns 0x1 on 32-bit architectures (bitmask is stored in a pointer-size variable, and 1 << 32 becomes zero so invert_range is a no-op). Perhaps we should limit parts of this test to 64-bit architectures? CCing Benjamin who is author of the commit c8c666c87c827323, where things broke.
Disclaimer: I'm kinda angry that the default assumption for a failing test is "maybe we should turn it off" instead of "something is broken and needs to be fixed". GtkBitmask is an infinite-length bitmask (it's like Vector<bool> in C++), so inverting the first 32 bits of it should work no matter what architecture you're running it on. It contains an optimization that stores the bitmask without allocating memory if the mask fits into a pointer (minus 1 bit used for indicating if this is an allocated bitmask or not). The value indicating this is GTK_BITMASK_N_DIRECT_BITS and should be 31 on i686. So I'm not sure how it ever gets to do a 32 bit shift because there should be checks in place (probably comparing with GTK_BITMASK_N_DIRECT_BITS). Could you (get a stack trace to) explain how and where it happens? Fwiw, we have tests inverting the range from 0 to [31, 32, 63, 64] trying to test all these corner cases and for 64bit these tests run fine.
It's not that sizeof(gsize) != sizeof(gpointer) for you?
Inside a Debian i386 chroot on top of amd64 install (which should be the same configuration used by debian i386 buildds): sizeof(gsize):4, sizeof(gpointer):4 Please note that the test fails on i386, mips and mipsel.... but not on some other arch which I believe are also 32bit like "powerpc", also armel and armhf.
fwiw, full build logs available by clicking "Build-Attempted" on https://buildd.debian.org/status/package.php?p=gtk%2B3.0&suite=experimental
Sorry, I was not familiar with GtkBitmask (actually this is the first time I heard about it), that's why I had wrong assumptions. Actually I just noted that it FTBFS on Debian buildds, and that was blocking some work for me. Now I have read all the code, and only now I can say that I know how it works :) I am away from PC now, but when reading the code one thing hurts my eye: in line 315 of gtkallocatedbitmask.c, there is an "end_bit != 63" check. Not sure if it is related to this bug, but should it be VALUE_SIZE_BITS - 1 instead of 63? I will do further debugging when I have time. If you want to test yourself, you should get this failure on any 32-bit x86 system.
commit 97293865b5c3e10fa65009e5f787312a17f47b06 Author: Dmitry Shachnev <mitya57@ubuntu.com> Date: Sun Sep 27 15:10:15 2015 +0200 bitmask: Don't hardcode 64bit size This looks like an oversight from "quickly testing a potential fix" and then forgetting to make a production-ready when it works. For people trying to add this fix to their builds: I pushed another commit right after that's just cleanup and *not* related to this bug. Just pulling this commit should fix things.
Benjamin, thanks for the commit, after applying it the tests pass fine on all Debian architectures.