La transition vers Boost-1.65.1 et les bogues qui ont fait surface

L'année dernière (presque toute une année s'est déjà écoulée), nous sommes néanmoins passés à la nouvelle version de Boost-1.65.1, et sous le capot, vous trouverez les trois bugs de boost que nous avons rencontrés. Il est également important de mentionner qu'avant cela, le boost -1.62.1 était utilisé dans notre logiciel, car certains bogues sont apparus dans le boost avant la version 1.65.1

Notre projet dispose d'une équipe d'intégration spéciale, dont la tâche principale est de migrer tous les logiciels vers une nouvelle version des bibliothèques, Visual Studio, de nouvelles versions de composants de bas niveau (de base, dont dépendent la plupart des autres composants), etc. L'équipe d'intégration est également chargée d'éliminer tous les problèmes qui surviennent, naturellement avec l'aide des mainteneurs de composants, si nécessaire. Donc, des bugs dont je me souviens particulièrement.

Bug dans boost :: filesystem

Ce bug est apparu assez rapidement. Les tests ont commencé à planter avec «Violation d'accès» lors de la recherche du chemin d'accès complet au nom de fichier donné. La fonction a lancé un appel à boost :: filesystem :: exist et le programme s'est bloqué. En exécutant quelques tests supplémentaires, plusieurs cas similaires ont été notés, et dans tous les cas, l'appel boost :: filesystem :: exist a été effectué pour les variables globales. Apparemment, quelque chose a changé dans la durée de vie des variables boost. Un ticket pour un bug détecté est très facile à google un ticket de bug dans boost :: filesystem :: exist

Il s'est avéré que ce bogue est entré en vigueur, à partir de la version 1.64. En fait, le problème était dans l'appel make_permissions (utilisé dans filesystem :: exist). En 1.64, l'implémentation de make_permissions a été modifiée et utilise désormais des variables globales, ce qui signifie que lorsqu'une tentative est faite d'appeler filesystem :: exist lors de l'initialisation d'une variable ou d'un objet global, les variables globales utilisées dans make_permissions peuvent ne pas encore être initialisées. Par conséquent, une tentative d'accès à une variable non définie lève une exception.

Bug dans boost :: python

Dans les tests utilisant boost :: python, une chose étrange a été découverte. Lorsque vous effectuez un appel trivial à eval () pour un littéral (par exemple, "40 + 2"), toutes les règles. Et si vous définissez les variables puis les utilisez dans des expressions, nous obtenons un message indiquant que les calculs utilisent des variables non définies (ERREUR: [nom] non défini). Pour résoudre ce problème, j'ai passé plus de temps. Je n'ai pas pu trouver de ticket pour ce problème dans le boost tracker, j'ai donc dû demander de l'aide à l'équipe de ce composant. Des informations sur le bug ont été rapidement trouvées sur github .

Il se trouve que dans l'implémentation d'eval, les objets globaux et locaux n'ont pas été utilisés. Ayant souhaité bonne chance pour trouver un correctif sans recompiler le code source, l'équipe a pris congé :)

boost :: numpy

C'est ma partie la moins préférée. boost :: python :: numeric a été supprimé et désormais boost :: python :: numpy est apparu comme une alternative. Mais le code qui utilisait le numérique a dû être repensé à peu près, car il ne s'agissait pas seulement de renommer l'espace de noms, mais aussi d'implémenter les objets.

De plus, il y avait une désinformation dans l'en-tête du boost qui m'a induit en erreur.
Selon le commentaire dans la source, l'appel import_array () est déjà fait dans numpy :: initialize ():

namespace boost { namespace python { namespace numpy { /** * @brief Initialize the Numpy C-API * * This must be called before using anything in boost.numpy; * It should probably be the first line inside BOOST_PYTHON_MODULE. * * @internal This just calls the Numpy C-API functions "import_array()" * and "import_ufunc()", and then calls * dtype::register_scalar_converters(). */ BOOST_NUMPY_DECL void initialize(bool register_scalar_converters=true); }}} // namespace boost::python::numpy 

Mais en fait, comme il s'est avéré, import_array () est nécessaire.

De plus, il y avait des problèmes avec le test des modifications, car les morceaux de code avec numpy (auparavant avec boost :: python :: numeric) n'étaient pas du tout couverts par les tests, et le code lui-même était également utilisé dans un autre composant. Par conséquent, les problèmes ont été identifiés uniquement lors du test du composant correspondant. L'équipe d'intégration n'est pas tenue d'écrire des tests pour les composants, et cette situation était une omission de l'équipe elle-même. Wow, j'en ai assez entendu d'eux pour casser leur code. Mais après que l'équipe ait grommelé, ils ont finalement couvert leur code avec des tests. Cependant, le ressentiment est resté (lors de la prochaine migration, l'équipe n'a pas voulu donner accès à leur composante à mon collègue, mentionnant que la dernière fois que nous avons brisé le code pour eux. Sasha, soryan! Mais après trois jours de négociations, ils ont abandonné).

Conclusion

Après le travail effectué, je peux noter les avantages pour moi-même, car le boost n'avait pas été utilisé très souvent auparavant (principalement std), donc beaucoup de choses peuvent être soulignées lors de la migration. C'est drôle, mais le fait est, après une telle raison, que pour une raison quelconque, vous ne devenez pas un "expert en boost" pour de nombreux collègues, et, réconciliez, on vous posera des questions à ce sujet pendant encore un certain temps.

Soit dit en passant, ces dernières années, de nombreuses entreprises ont commencé à se débarrasser activement de boost et de remplacer la bibliothèque std si possible, ou autre chose en l'absence de fonctionnalités dans la bibliothèque standard. Et nous aussi, nous ne sommes pas restés à l'écart. Le processus est commencé, mais pas terminé, il y a encore beaucoup de travail.