Use reliable int type for mesh size in draw_quad_mesh (#7788) #7791
Conversation
In the agg backend, `PyRendererAgg.draw_quad_mesh` takes mesh dimension arguments (`mesh_width` and `mesh_height`). When converting those from Python to C, we were declaring the C types as `size_t`, but converting from Python using the 'I' format specifier, which converts a Python integer to a C unsigned int. As @QuLogic spotted, this isn't safe, because `size_t` is not necessarily the same size as an int. On Fedora with GCC, for instance, `size_t` is an alias for long unsigned int. On LE arches this usually won't cause a problem, but on a BE arch where `size_t` isn't an int type, the mismatch causes rendering errors (see matplotlib#7788). This addresses the problem by just changing the types for these values to be `unsigned int` instead.
Current coverage is 62.12% (diff: 100%)@@ master #7791 diff @@
==========================================
Files 174 174
Lines 56028 56028
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
Hits 34805 34805
Misses 21223 21223
Partials 0 0
|
|
Since people were interested in when these BE issues appeared, in this case, this code was changed in ba40160 , "Remove use of PyCXX in core C++ extensions", which has been around since (I think) 1.5.0. I can't say for 100% sure if the old code would have worked properly on BE, but it looks more likely to have worked, to me. The relevant bit of the old code looked like this: |
|
@AdamWill Thanks for tracking that down! The question at hand is we are about to do a 2.0 release, do we want to include all of your cpp work and does it require another rc? I am leaning towards yes and no. Yes to include, because we are just flat broken on BE machines (and have been for about 2 years apparently) which seems like a high priority to fix. No to requiring another RC because this is all down in the extension layer which is well tested (on LE) and for the most part not user-visible. |
|
As I'm primarily concerned with Fedora, I don't really have too much of an opinion, as I'm going to backport these changes to the Fedora packages regardless. You're in a better position than I to decide how important and dangerous the changes are. Note there are still 14 test suite errors I haven't tracked down yet, will file an issue for those shortly, but if you want a quick preview: https://paste.fedoraproject.org/525296/95891148 |
|
@sandrotosi it would be interesting to cross reference these against the debian builds. |
|
i gave a quick look at mips (BE) and ppc64 (BE, but not a release architecture for debian) and we dont seem to have the 'arrays are not equal' failures, but on the other side we have a shitload of 'images are not close', likely due to our fancy fonts FWIW i agree with @tacaswell to include those changes and that they dont require a new rc - downstream distros know how to scream loudly if things break ;) |
|
I agree with the "include, no rc" strategy for this. |
|
@sandrotosi the Fedora package has a patch which changes the default value of We also individually patch the tolerances for a few other tests which seem to behave slightly differently on different arches; the package maintainer has filed bugs for some of these, but not all of them. They're mostly stuff like very slightly different color shades, or the 'notches' on an axis (sorry, don't know the technical term) not being drawn in the same place. If you want to check if Debian is hitting this specific error, look for image comparison failures in the |
|
👍 |
|
Backported to v2.x as 248f47a |
Use reliable int type for mesh size in draw_quad_mesh (#7788)
|
👍 on "include, no rc" as well. |
|
@AdamWill thanks for the reference, i just imported http://pkgs.fedoraproject.org/cgit/rpms/python-matplotlib.git/plain/python-matplotlib-increase-tests-tolerance.patch in the debian packaging, let's see how happy it is now the testsuite :) |
In the agg backend,
PyRendererAgg.draw_quad_meshtakes meshdimension arguments (
mesh_widthandmesh_height). Whenconverting those from Python to C, we were declaring the C
types as
size_t, but converting from Python using the 'I'format specifier, which converts a Python integer to a C
unsigned int. As @QuLogic spotted, this isn't safe, because
size_tis not necessarily the same size as an int. On Fedorawith GCC, for instance,
size_tis an alias for long unsignedint.
On LE arches this usually won't cause a problem, but on a BE
arch where
size_tisn't an int type, the mismatch causesrendering errors (see #7788).
This addresses the problem by just changing the types for these
values to be
unsigned intinstead.Along with my other recent PRs, this gets the test suite error count in a Fedora ppc64 build down to 16. Nearly there...