Je trouve vos assertions très cavalières. :weird:
Citation:
- S'il y a une couille quelque part, pourquoi mon environnement de debug sous Windows serait plus permissif que l'environnement debug sous Linux ou bien même la prod (dans un container Docker / Alpine) ?
Les environnements ne sont pas plus ou moins permissifs selon une échelle de "permissivité" absolue. Ils sont complètement différents.
Si vos outils bricoli/bricolette fonctionnent correctement (ou semble fonctionner correctement) dans un environnement, absolument rien ne garantit que cela fonctionnera dans un autre, surtout si vous avez fait des assertions lors de l'implémentation/bricolage des outils sur la manière dont fonctionne tous les environnements.
C'est là un des avantages majeurs des outils standards, ils ont été lourdement testés et validés sur un ensemble énorme d'environnement et en évitant de faire des assertions sur la manière dont fonctionne chaque environnement.
L'environnement de Debug de Visual Studio (pas Windows, encore une assertion sur le fait que tout fonctionne à la Linux) est plus tatillons sur l'utilisation de paramètre, les invariants, etc mais beaucoup moins sur les pointeurs non initialisés, etc... etc...
Citation:
Sachant que sous Linux, le moinde pet de travers et c'est "segmentation fault" direct, ça ne pose pas de question
C'est absolument FAUX, à moins d'y coller des outils comme valgrind, et encore.
Si vous voulez le même type d'outils pour psychopathe de l'utilisation mémoire sous Windows, je peux vous en fournir quelques-uns.
Citation:
- On a modifié l'accès à la gestion mémoire, sous Linux en debug ou en prod dans le container ça se comporte pareil, par contre sous Windows à rattacher MSVC au process Node, ça "crash moins'.
Le simple fait d'attacher un débogueur à un exécutable change tout le scheduling des threads, donc des allocations, le mapping mémoire, etc...
Et ce n'est pas une anomalie, ces changement peuvent aussi arriver en fonction de la charge CPU, du disque, du type de CPU, etc...
Si ça bug avec le débogueur et pas sans, le débogueur n'est qu'un révélateur d'un vrai problème, votre code n'est pas "stable".
Si à l'inverse, avec le débogueur ça bug moins, c'est que le débogueur "stabilise" malgré lui votre code bancal.
Mais vous pouvez le prendre dans n'importe quel sens, le problème est dans votre code, pas dans l'environnement, qui ne fait que le subir.
Citation:
Pourquoi ça crash sous Windows, selon son humeur du moment, et jamais sous le triplet (Linux / Docker / Alpine) ?
Un ordinateur n'a pas d'humeur.
S'il crash, c'est qu'il y a un problème.
Problème qu'il est facile de circonscrire si on prend la peine de lire le contenu des fichiers de DUMP générés à ce moment et de disposer des sources afférents.
Pour moi, l'exécution sus Windows ne fait que révéler un problème dans votre code.
Si vos développement n'ont pas à s’exécuter sous Windows, peut-être que les limitations de votre implémentation sont "licites", mais il est plus probable que les problèmes sous Windows en sont que des révélateurs de problèmes plus profonds.
Citation:
- Pourquoi ça a amélioré le truc en debug sous Windows, alors que fondamentalement rien n'a changé ?
Le passage en debug change ÉNORMÉMENT de choses.
Ne jamais dire, "ça marche en Debug donc ça marchera en Release" NON, NON, NON !!! :weird:
Si ça plante en Debug, profitez de cette aubaine pour voir où ça plante en Debug.
Mais il peut avoir des problèmes qui ne seront détectable qu'en Release.
Citation:
- Pourquoi il y a encore des problèmes dans ce contexte alors qu'en prod sous Docker / Alpine ou en dev dans des VM et sous Docker / Alpine ou en dev directement sur les machines ça ne rechigne pas ? Ce sont quand même des environnements sensés être très contraignants dès que l'on fait un pet de travers, par rapport à Windows, non ?
Non.
Citation:
Par contre je viens de penser à un truc, c'est qu'on utilise boost pour boost::chrono et boost::posix_time et je n'ai pas souvenir d'avoir compilé les libs spécifiquement pour 32 ou 64 bits sous Windows dans la commande b2. Ce peut être une source de variabilité, mais étant donné que c'est lié en statique, est-ce que des erreurs de compilation seraient provoquées en cas de non compatibilité ?
Oui, le linker aurait gueulé comme un putois.
Le plus simple, c'est de le faire planté en environnement DEBUG, soit sous débogueur, soit en générant in fichier de DUMP au moment du crash.
Donnez-nous les informations que le débogueur fourni pour voir ou chercher les problèmes.