Déboguer une DLL utilisée par un module NodeJS natif avec VS

Bonjour à tous,

Je travaille sur un sujet concernant de l'optimisation combinatoire. Mon environnement de production est Linux (Ubuntu) mais pour le dev je privilégie Windows et VisualStudio pour les facilités de débogage, une phase importante dans ce type de sujet où l'on ne peut pas s'en sortir à coups de simple logs.

J'ai essayé code::blocs mais je ne sais pas si c'est parce que ça tournait dans une VM Ubuntu Desktop ou quoi, en tout cas l'expérience s'est avérée négative (IHM qui déconne, impossibilité de déboguer ce qui se passait dans les threads, etc.).

J'ai également essayé l'addon Visual Studio permettant de déboguer à distance avec gdbserver en s'attachant au process distant en question. Ça fonctionne bien, très bien même, mais on ne retrouve pas l'aisance nécessaire (pouvoir mettre en pause à tout moment, les asserts ne sont pas catchés, impossibilité d'arrêter une compilation cours, d'activer un point d'arrêt en cours d'exécution etc.).

Voici mon archi pour cette partie là :
- Une DLL C++
- Chargée par un module natif Node à coups de LoadLibrary sous Win32 et dlopen sous Linux
- Une exposition HTTP via ExpressJS
- Une application Web qui consomme l'API HTTP

Le but étant de pouvoir générer la DLL et la déboguer dans MSVC après avoir lancé le traitement sur l'interface WEB.

La DLL utilise la bibliothèque jsoncpp et pour une raison que j'ignore, ça ne fonctionne pas en x64 (une assertion est levée concernant un check sur du max int value). Je n'ai pas cherché plus loin et pour du debug, j'ai tout claqué en 32bits (version de NodeJS, compile jsoncpp, compile module node natif et compile DLL, tout en 32bits).

Dans les options de débogage VS :
- Command : C:\Program Files (x86)\nodejs\node.exe
- Working Directory : C:\dev\mon-service-node
- Command Arguments : bin\www (le point d'entrée par défaut d'un service Express)

Je lance le débogage, je lance le traitement, le débogueur est activé et le traitement tourne, je peux le mettre en pause, mettre les points d'arrêt quand je veux, tout est nickel.

Jusqu'à un moment où je me prends des erreurs de violation d'accès mémoire, de manière aléatoire, de type aléatoire. Certaines arrivent en tout début d'exécution, je relance le tout et ça passe, sans rien changer au code.

J'ai eu ceci :

Citation:

---

Unhandled exception at 0x06C1635F in node.exe: 0xC0000005: Access violation reading location 0x7BD7A5CC

---

Citation:

---

Exception thrown at 0x0F4B3CC0 (ucrtbased.dll) in node.exe: 0xC0000005: Access violation writing location 0x06913FC4.

---

C'est pas très courant comme organisation mais quelqu'un saurait me dépanner pour obtenir un schéma fiable ? Peut-être y a-t-il des options à configurer dans les différentes compilation ? Actuellement tout est compilé en '/MTd'.

Il faut savoir que ma mémoire (8Go) dépasse souvent les 7,5Go utilisés et que le traitement agit beaucoup sur la mémoire et en débug peut durer plus de 20 minutes, peut-être y a-t-il des trucs liés à la fragmentation ?

Toujours est-il que sous Linux, ça tourne jusqu'au bout sans la moindre erreur.

Merci par avance,

A bientôt

Une autre :

Citation:

---

Exception thrown at 0x0F9D843F (Algo.dll) in node.exe: 0xC0000005: Access violation reading location 0x07A1F018.

---

Après 20min44 de session debug (sans arrêt)

Salut,

De manière génrale, ce genre de bug aléatoire est le plus souvent du, en C++, à une tentative de déréférencement d'un pointeur invalide.

Plusieurs raisons peuvent faire qu'un pointeur est invalide:

• il vaut explicitement nullptr (mais il est alors connu pour représenter une adresse invalide, et on peut donc placer une assertion sur le fait qu'il doit valoir "autre chose")
• l'adresse mémoire représentée par le pointeur a été libérée, mais la valeur du pointeur n'a pas été remise à nullptr
• un mauvais transtypage faisant que l'on a un pointeur connu pour pointer sur une donnée de type Type1 alors que c'est une donnée de type AutreType qui se trouve à cet endroit,
• d'autres raisons encore qui ne me viennent pas forcément à l'esprit maintenant.

Pour ce qui est des problèmes de transtypage, il n'y a qu'une solution: renonce définitivement à toute pratique ayant recours au (pseudo) RTTI: Si tu as été "assez bête" (ou peut-être simplement forcé) de perdre le type réel (dynamique) d'une donnée lorsque tu en as pris l'adresse, tu dois mettre en oeuvre des pratiques basées sur les comportements polymorphes (les fonctions virtuelles) et le double dispatch pour travailler avec le type dynamique.

Ce n'est pas (loin s'en faut) une technique exempte de problème, mais le patron de conception visiteur est un exemple de ce que l'on peut faire dans ce cas là.

Si tu respecte correctement le LSP, cette décision te permettra en outre d'améliorer le respect que tu as de l'OCP, ce qui ne pourra qu'améliorer la qualité générale de ton projet; tant en termes de fiabilité qu'en terme d'évolutivité ou de facilité à la compréhension ;) .

Pour le reste, je présumes que tu utilises des pointeurs nus... Ce qui est une très mauvaise idée:

Depuis l'arrivée de C++11, nous disposons dans la bibliothèque standard de pointeurs intelligents, qui sont d'ailleurs basés exactement sur le modèle de ceux de boost. Le compilateur de Visual Studio 2017 supporte parfaitement non seulement C++11, mais aussi C++14 (et certains aspects de C++17), alors que celui Visual Studio 2015 ne supportait pas l'intégralité de C++11 (il avait, par exemple, un problème avec les fonction deleted et defaulted).

Peut être devrais tu envisager de mettre ton code "a jour" au vu de ces nouvelles normes. Tu verras, les fonctionnalités qu'elles fournissent te rendront la vie de développeur bien plus belle :D

Si, pour une raison ou une autre, tu ne devais pas pouvoir disposer des fonctionnalités des normes modernes (C++11 et ultérieures), essaye au moins de faire en sorte que les classes qui manipulent des ressources (comme les pointeurs) soit des "capsules RAII":

1. Chaque élément dans ce cas ne doit avoir la responsabilité que d'une et une seule ressource: C'est lui qui décide quant il faut la créer, mais c'est aussi lui qui veille à ce que la ressource soit correctement détruite lorsqu'il est lui-même détruit
2. Pour les éléments ayant sémantique d'entité, veille à en interdire la copie et l'affectation en plaçant le constructeur de copie et l'opérateur d'affectation dans l'accessibilité privée sans les implémenter
3. Pout les éléments ayant sémantique de valeur, veille à respecter la règle des trois grands: si, pour une raison ou une autre, tu en viens à fournir une implémentation personnelle du constructeur de copie, de l'opérateur d'affectation ou du destructeur, tu dois veiller à fournir l'implémentation des trois. Penses, pour t'y aider, à la forme canonique orthodoxe de Coplien ;). Un idome régulièrement utilisé dans ce cas est l'idiome copy and swap.
4. Enfin, veille toujours à vérifier -- de préférence au travers d'une assertion -- que tous les pointeurs que tu manipulent ne sont pas égaux à nullptr. Si tel est le cas, il s'agit d'une erreur de logique qui mérite d'être corrigée avant la mise en prod ;)

En plus des conseils de @koala01, que j'approuve sans réserve, je vais faire des remarques plus "tactiques" (court terme).
Bon, même si cela n'a pas été la première solution envisagée, vous êtes arrivé à une configuration qui marchouille, c'est bien.
Un truc qui peut posé pas mal de problèmes erratiques, c'est de mélanger des Runtime Release et des Runtime Debug.
"node.exe" utilise une C-Runtime Release et votre Dll une C-Runtime Debug, si l'API utilisé n'est pas étanche d'un point de vue mémoire, ça va pas trop le faire.
Je vous conseille donc de compiler avec les informations de Debug (les fichiers .pdb) même en Release, et d'utiliser la version Release durant vos sessions de débugging.
C'est un tout petit peu moins confortable qu'en Debug, mais c'est encore pas mal.
De plus, si l'API n'est pas étanche et que "node.exe" n'utilise pas la même C-Runtime (compilé avec un autre compilateur), même en Release, ça risque aussi de partir en sucette.
Par étanchéité, c'est le fait que l'allocation, la libération et les déplacements d'une zone mémoire soient exécutés par le même module binaire (dll, exe).
Après, si le problème est bien un problème d’étanchéité de l'API, vous devriez commencer par la rendre étanche.

Citation:

---

Toujours est-il que sous Linux, ça tourne jusqu'au bout sans la moindre erreur.

---

Sous Linux, la C-Runtime est commune à tout les exécutables, je crois, donc des API C qui fuite, ça passe.
Mais je crois que le problème se posera aussi sous Linux si l'API est C++, car je crois que la C++-Runtime n'est pas commune même sous Linux.

Citation:

---

Jusqu'à un moment où je me prends des erreurs de violation d'accès mémoire, de manière aléatoire, de type aléatoire. Certaines arrivent en tout début d'exécution, je relance le tout et ça passe, sans rien changer au code.

---

C'est un heisenbug.
Votre programme ne tourne pas dans le cosmos soumis au rayonnement ionisant du soleil. S'il plante c'est qu'il est buggé.
Quand ça plante, analysez le problème. Le débogueur donne tous les outils pour comprendre pourquoi c'est parti en sucette, même si ce n'est pas systématique.

Merci pour vos réponses,

A vrai dire il n'y a pas d'héritage dans ce projet, ni d'allocation dynamique durant l'exécution des algorithmes.

Au début de l'utilisation, on alloue tout ce dont on a besoin ce qui constitue le terrain de jeu mémoire, et en fin d'exécution on release tout.

On utilise le C++ et la méta programmation pour gagner un max de temps à l'exécution et les types manipulés ne sont que des types primitifs, des tableaux et des boost_datetime.

On n'utilise pas non plus les RTTI, je déteste ça, c'est "dégueulôsssse"

J'ai encore regardé et il n'y a aucune allocation dans le module node dont la data est transmise à la DLL, ni dans la DLL pour recevoir des data dans le module node, tout est passé en primitive, aucune classe, aucune structure.

Cela n'exclu pas un bug, j'ai toujours toujours des doutes sur mes productions, d'où le blindage de TU qui dépassent le cadre purement fonctionnel. En fin d'utilisation du service il y a un test d'intégrité pour valider que tous les indexes références les bonnes data, rien à -1 alors que ça ne devrait pas l'être.

J'ai déjà eu des soucis logiques qui m'ont donné des erreurs "segmentation falt" lorsque j’accédais en lecture ou écriture en dehors de la zone mémoire qui m'était allouée. Ça ne crashait pas durant l'exécution mais une fois qu'on releasait la mémoire allouée, donc ça se voit tout de suite.

Peut-être qu'il y a une portion de code entre des #ifdef WIN32 qui sont buguées, ce peut être une piste également mais elles sont très peu nombreuse ces portions et ne font rien si ce n'est inclure un fichier ou un autre ou utiliser une fonction ou une autre (LoadLibrary VS dlopen).

En revanche je commencerais bien par chercher à être sûr du mélange des modes de compilation, et n'ai pas vraiment la main sur les options par défaut que met node-gyp dans le fichier projet généré avant d'appeler msbuild.

Lorsqu'il y a une brique qui utilise un autre runtime qu'une autre brique, j'ai des erreurs me l'indiquant, mais peut-être que d'autres options sont "incompatibles" ?

Je vais essayer de tout compiler en release avec les symboles de debug voir ce que ça donne mais si il faut ça reviendra aux mêmes possibilités de debug que j'ai actuellement quand je fais avec linux via gdbserver.

C'est contrariant en tout cas :'(

Merci encore,

A bientôt

[Edit] Info peut-être utile : Jusqu'il n'y a pas longtemps je pouvais faire tourner le moteur sous Windows dans la mesure où il possédait sont propre serveur HTTP embarqué en utilisant PION Network Library), mais depuis on a préféré faire porter cette couche là par NodeJS / Express car PION devenait non supporté

Citation:

---

Envoyé par mister3957

Merci pour vos réponses,

A vrai dire il n'y a pas d'héritage dans ce projet, ni d'allocation dynamique durant l'exécution des algorithmes.

Au début de l'utilisation, on alloue tout ce dont on a besoin ce qui constitue le terrain de jeu mémoire, et en fin d'exécution on release tout.

---

Il y a donc bel et bien une allocation dynamique de la mémoire "quelque part", et une libération de celle-ci "ailleurs".

Pourrais déjà nous montrer au minimum les fonctions qui s'occupent de ces deux parties :question:

Mais bon, si tu a la certitude que les pointeurs ne sont pas en cause, voici d'autres pistes de réflexion ;)

1- Vérifie tes conversions, surtout si tu fais des transtypages "sauvages" (par exemple, de short vesr un int ). Si tu en fais, utilise de préférence static_cast au transtypage "C style" ( (int)monShort; )

2- Méfies toi des conversion de valeurs signées en valeurs non signées (et inversement)

3- Surveilles tes indices, et assures toi en permanence (à l'aide d'assertion, par exemple), que tu n'essayes pas d'aller "une case trop loin"

Il y en a surement d'autres, mais elles me viendront à l'esprit "plus tard" ;)

Autre chose, as-tu activé un maximum de warning de compilation?
Si oui, en as-tu corrigé par un cast (ce qui est souvent la mauvaise solution)?
En as-tu masqué dans ton code?

Ha j'ai peut-être trouvé quelque chose.

Dans les data on ne deal qu'avec des buffers, un peu comme ce que l'on fait en 3D pour remplir les buffers de la carte graphique :

Code:

---

1 2 3 4 5 6

// A l'initialisation : void* pData = malloc(uiSize * sizeof(SProperty<X>::TType));   // Récupération : void* ret = (void*)((long)pData + (iIndex * sizeof(SProperty<X>::TType)));

---

C'est ce (long) sur pData qui me taraude sur une possible différence entre 64 bits et 32 bits.

Et on fait pareil pour le set (memcpy((long)pData + ......)

Ça ne me paraît pas top. Vous en pensez quoi (à part le static_cast<long> que je m'empresse d'utiliser) ?

On va y arriver ;)

En tout cas merci pour votre aide !

[Edit] En plus on connait le type de pData, je vais modifier en ((static_cast<SProperty<X>::TType*>(pData))[iIndex]

Clairement, ton cast en long ici est trop cavalier, la taille d'un long dépend de la machine http://en.cppreference.com/w/cpp/language/types
Le cast n'est-il pas superflu de toute façon ?

Aussi, tu devrais favoriser l'utilisation de new et reinterpret_cast

Ok d'acc, je fais ça ce soir, je test et reviens vers vous ;)

Merci

En fait, puisque tu décales d'un multiple de la taille du type pointé, la bonne syntaxe, c'est: void* ret = pData + iIndex;Un pointeur désigne est typé pour une très bonne raison: l'adresse d'un bloc mémoire alloué normalement (par la pile ou par malloc) est alignée sur la taille du bloc.
si p est un pointeur de T, p+1 est aussi un pointeur de T, donc, il désigne le T situé juste après celui désigné par p.


Et comme ta variable s'appèle ret, je suis prête à parier que tu peux même écrire return pData+iIndex;.

J'en profite pour raler parce que tu utilises la notation hongroise, qui a le défaut de ne pas être uniforme.
pData semble être un pointeur, mais p pourrait aussi désigner un paquet réseau, un parametre, ou un POD.
iIndex est-il un itérateur ou un entier? signé ou non? constant ou non (plutot pour l'itérateur)?

Citation:

---

Envoyé par ternel

En fait, puisque tu décales d'un multiple de la taille du type pointé, la bonne syntaxe, c'est: void* ret = pData + iIndex;Un pointeur désigne est typé pour une très bonne raison: l'adresse d'un bloc mémoire alloué normalement (par la pile ou par malloc) est alignée sur la taille du bloc.
si p est un pointeur de T, p+1 est aussi un pointeur de T, donc, il désigne le T situé juste après celui désigné par p.


Et comme ta variable s'appèle ret, je suis prête à parier que tu peux même écrire return pData+iIndex;.

---

Sauf que pData est un void*, donc ton décallage doit être multiplié par la taille des données et un simple + index ne suffit pas et retournerait le milieu d'un objet si les objets sont plus gros qu'un char.
Donc soit return reinterpret_cast<SProperty<X>::TType*>(pData) + iIndex; soit return pData + iIndex * sizeof(SProperty<X>::TType);

Certes, mais dans ma tête, j'ai fais le raccourci, parce qu'un pointeur vers quelque chose devrait être du type de cette chose.
Pourquoi pData est-il un void*, s'il doit pointer sur des SProperty<X>::TType?

Je pencherais plus sur le cast du pointeur, à défaut de le typer correctement, plutot que de reposer sur l'arithmétique d'un pointeur void

Voici ce que j'ai fait :

- J'ai remplacé le cast (long) + index * sizeof() par le reinterpret_cast<SProperty<X>::TType*>(pData) + index
- J'ai mis des assert (en vérité des points d'arrêts) concernant l'index demander afin de m'assurer qu'il n'était pas < 0 et >= count

Sur mon contexte "production", ça a crashé dès le début, j'ai relancé, ça a racrashé encore au début, j'ai relancé et ça a finalement déclenché le traitement qui a crashé au bout de 20 minutes et 35 secondes.

Les points d'arrêts ne se sont pas déclenchés, donc pas de problème de demande de zone d'accès en dehors des limites allouées.

C'est un module de calculs combinatoire qui fait beaucoup d'opérations mémoire par seconde et quand ça trouve une meilleure combinaison, ça produit une log disant "j'ai trouvé ci, j'ai trouvé ça, en faisant ci et ça à cet endroit là". En comparant, ça produit les mêmes logs qu'en production.

Du coup j'ai testé sur un problème plus restreint, donc plus rapide à s'exécuter, et sur deux tests, j'ai un crash au moment du "free", en fin de traitement.

Il y a donc bien un loup quelque part dans la gestion mémoire, une revue de code en mode remise en question s'impose ;-)

Citation:

---

Envoyé par ternel

Certes, mais dans ma tête, j'ai fais le raccourci, parce qu'un pointeur vers quelque chose devrait être du type de cette chose.
Pourquoi pData est-il un void*, s'il doit pointer sur des SProperty<X>::TType?

Je pencherais plus sur le cast du pointeur, à défaut de le typer correctement, plutot que de reposer sur l'arithmétique d'un pointeur void

---

Oui c'est con, si on connait le type autant s'en servir, je sais pas pourquoi j'ai fait ça à l'époque

A ce niveau-là, autant passer à un std::unique_ptr (pour la désallocation) de std::array (pour la tabularité).

Oui pourquoi pas,

Si ce couple std::unique_ptr / std::array ne consomme pas plus de CPU pour s'auto gérer et s'utiliser en random access, c'est effectivement envisageable.

J'ai nettoyé à coups de reinterpret_cast<>[index] partout. Depuis je n'ai plus eu aucun crash en début d'exécution, c'est bon signe.

Parfois ça crash au niveau des "free()" en fin de traitement, de manière aléatoire sur le nettoyage de telle ou telle data, et sur un cas il n'y a pas eu de problème.

J'aimerais bien dégager ces malloc / free pour aller vers du new[] / delete[], mais comment lorsque la taille du tableau à allouer n'est connue qu'à l'exécution ?

std::vector

En ce cas, tu peux passer par std::vector, et un appel à sa fonction reserve.

Comme vector est susceptible de faire une réallocation si la taille est insuffisante pour une insertion, ce n'est pas forcément la solution idéale.

Il te faut apparemment répondre à plusieurs contraintes:
Une seule allocation, à un moment précis.
Une taille maximale fixe, mais inconnue à la compilation.
Une allocation hors de la pile (sur le tas, donc).
L'espace d'allocation est ni copiable ni déplaçable.

Cela ressemble aux problématiques des allocateurs.
Peut-être devrais-tu utiliser utiliser std::vector<int, super_allocator>.

Ton allocateur te fournirait l'accès à ta zone mémoire préallouée, en simulant gérant les allocations dedans.
Renseigne-toi aussi sur ce que sont les placement new et placement delete. (Bidule* = new (adresse) Bidule();)

Peu n'importe le contenant, l'important c'est le contenu ^^

On verra plus tard les array / vector mais je ne pense pas que ce soit une bonne solution dans mon contexte dans la mesure il la gestion mémoire conserve les opérations effectuées afin de revenir en arrière plus tard (des espèces de rollback). En cas de réallocation par un conteneur, je n'ai pas les moyens de mettre à jour les adresses pointées et stockées pour revenir en arrière plus tard, et encore moins si je ne sais pas lorsqu'elles ont changées.

C'est pourquoi je n'utilise plus de realloc. Dans un environnement dédié ça fonctionnait car les adresses retournées étaient toujours les mêmes, mais lorsque je suis passé sous conteneur Docker, ça changeait et je n'avais pas, et n'ai toujours pas, la gestion nécessaire pour intégrer ces changements d'adresses pointées.

Toujours est-il que ça a fait avancer quelque chose le fait d'utiliser des accès tableau "traditionnel" plutôt que des "cast en long + des sizeof() * index" ainsi que des "value =" plutôt que des "memcpy" avec des reinterpret_cast<>[index].

En effet :
- Plus aucun plantage sous Windows en debug en tout début de traitement (au moment où on a alloué sans utiliser)
- Le contexte "mini moi" passe jusqu'au nettoyage de la mémoire en fin de traitement, même en relançant le traitement plusieurs fois sans réinitialiser le service
- Les résultats sont les mêmes en Debug / Windows 32 bits qu'en prod sous Docker / Release / Linux / 64 bits avec et sans le nettoyage concernant l'accès des zones mémoire

En revanche sur le vrai contexte, ça plante toujours au bout de 20 - 25 minutes en mode debug sous Win32.

C'est peut-être dû à des limites matérielles ?

Citation:

---

Envoyé par mister3957

Peu n'importe le contenant, l'important c'est le contenu ^^

---

Dans n'importe quel autre langage que C++ (ou que C), on aurait pu être d'accord avec toi.

Mais, là, tu codes en C++, et c'est un langage tout à fait particulier, qui est bien plus permissif que les autres.

Du seul fait de cette permissivité, tu te retrouves avec beaucoup plus de responsabilités que ce que tu ne pourras jamais avoir avec aucun autre langage! Et si tu n'assumes pas correctement les responsabilités que te donne le langage, tu n'arrivera jamais à rien.

En l'occurrence, le langage te délègue la responsabilité de veiller à ce que tes données soient correctement maintenues en mémoire, et à ce que la mémoire qui leur est allouée est correctement libérée lorsque la donnée et cesse d'exister.

Seulement, les spécificités du langage transforment cette responsabilité en véritable casse-tête sur laquelle même les plus grands experts en viennent à se casser les dents.

Car il ne s'agit pas de se dire "bah, j'alloue de la mémoire ici, je libère la mémoire là bàs, et le tour est joué"!!! Entre "ici" et "là bas", il y a trente-six raisons qui peuvent faire que tu te retrouve avec une double libération de mémoire, une fuite mémoire ou un dépassement de capacité.

Et ce sont donc trente-six raisons qui font que tu te retrouveras, au mieux, avec un bug systématique et reproductible, au pire, avec un comportement indéfini qui se traduira par un heisenbug, totalement aléatoire et impossible à reproduire.

Ta chance, c'est qu'il y en a déjà d'autres qui se sont cassé la tête sur le problème depuis bien longtemps, et qu'ils ont mis au point une série de classes qui fonctionnent correctement et de manière fiable.

Citation:

---

On verra plus tard les array / vector mais je ne pense pas que ce soit une bonne solution dans mon contexte dans la mesure il la gestion mémoire conserve les opérations effectuées afin de revenir en arrière plus tard (des espèces de rollback).

---

On se fout pas mal de savoir si tu choisira std::array, std::vector ou même std::set ou std::multimap. Ce que l'on veut, c'es que tu commences à les utiliser maintenant.

Et on ne le veut même pas d'une manière strictement égoïste! on le veut parce que l'on sait que cela te facilitera la vie, et que la seule utilisation de ces fonctionnalités a de grande chances de résoudre tes problèmes.

Citation:

---

En cas de réallocation par un conteneur, je n'ai pas les moyens de mettre à jour les adresses pointées et stockées pour revenir en arrière plus tard, et encore moins si je ne sais pas lorsqu'elles ont changées.

---

Dans ce cas, utilises des indexes au lieu d'utiliser des adresses mémoire. Et si tu tiens absolument (ou que tu n'as pas d'autre choix que de) à utiliser des adresses mémoire, choisi un type de collection, peut-être moins cache-friendly, qui puisse te garantir qu'une donnée ne "déménagera" pas au gré des changements de taille, comme std::list par exemple!

Citation:

---

C'est pourquoi je n'utilise plus de realloc. Dans un environnement dédié ça fonctionnait car les adresses retournées étaient toujours les mêmes, mais lorsque je suis passé sous conteneur Docker, ça changeait et je n'avais pas, et n'ai toujours pas, la gestion nécessaire pour intégrer ces changements d'adresses pointées.

---

Et si tu revoyais la structure de ton conteneur:question: Comme je l'ai dit, std::list a beau être moins rapide qu'un tableau en termes d'accès au données, elle peut garantir que chaque élément restera à l'adresse qui est la sienne lors de sa création.

Citation:

---

Toujours est-il que ça a fait avancer quelque chose le fait d'utiliser des accès tableau "traditionnel" plutôt que des "cast en long + des sizeof() * index" ainsi que des "value =" plutôt que des "memcpy" avec des reinterpret_cast<>[index].

En effet :
- Plus aucun plantage sous Windows en debug en tout début de traitement (au moment où on a alloué sans utiliser)
- Le contexte "mini moi" passe jusqu'au nettoyage de la mémoire en fin de traitement, même en relançant le traitement plusieurs fois sans réinitialiser le service
- Les résultats sont les mêmes en Debug / Windows 32 bits qu'en prod sous Docker / Release / Linux / 64 bits avec et sans le nettoyage concernant l'accès des zones mémoire

En revanche sur le vrai contexte, ça plante toujours au bout de 20 - 25 minutes en mode debug sous Win32.

C'est peut-être dû à des limites matérielles ?

---

... Ou à quantité d'autres raisons que nous ne pourrons malheureusement pas découvrir sans aller voir le code...

Configurez la production pour générer un DUMP lors d'un crash et analysez ce DUMP pour voir le motif du crash.

Tout ça me laisse pantois :

- 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) ?

Sachant que sous Linux, le moinde pet de travers et c'est "segmentation fault" direct, ça ne pose pas de question

- 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'.

Koala01 : Je ne rechigne pas à utiliser les dernières normes C++ ou les conteneurs de la STL, ce serait même une très bonne démarche (tu prêches un converti),

Mais (et sûrement par manque de connaissance sur le sujet, bien que 15 piges à travailler avec cette bestiole qu'est le C++), j'ai trouvé plus judicieux de dealer avec des tableaux basiques que des containers de la STL sur ce sujet spécifique, sinon évidemment que j'aurais fait péter les vector / array / list etc.

Pourquoi ça crash sous Windows, selon son humeur du moment, et jamais sous le triplet (Linux / Docker / Alpine) ?

C'est sûr que je ne suis pas clean quelque part, c'est évident.

Citation:

---

Envoyé par mister3957

Mais (et sûrement par manque de connaissance sur le sujet, bien que 15 piges à travailler avec cette bestiole qu'est le C++), j'ai trouvé plus judicieux de dealer avec des tableaux basiques que des containers de la STL sur ce sujet spécifique, sinon évidemment que j'aurais fait péter les vector / array / list etc.

---

A ceci près que, pour une "raison inconnue" (en l'état de nos propres connaissances de ton projet), ta démarche de ne pas utiliser les classes container pose visiblement un problème.

Tu as beau dire "ce n'est qu'en débug et sous windows", tu le dis toi-même:

Citation:

---

C'est sûr que je ne suis pas clean quelque part, c'est évident.

---

Et il est vrai que microsoft a tendance à faire énormément d'assertions dans son code debug (sans doute bien plus que Gcc, une manière d'essayer d'améliorer sa propre qualité :question:), ce qui est sans doute la raison de tes plantages.

Mais, en attendant, même si c'est en debug (je dirais bien : surtout si c'est en débug, car les perfs attendues sont loin d'être aussi importantes qu'en prod), il vaut peut-être mieux avoir quelque chose qui fonctionne lentement que quelque chose qui plante rapidement, tu ne crois pas :question:

Commences par faire quelque chose qui fonctionne correctement NDD! tu feras quelque chose de rapide par la suite ;)

Le truc c'est que ça fonctionne, c'est rapide, mais un peu chiant à déboguer sous Linux avec gdb à distance via gdbserver et l'addon Linux sous Visual Studio.

On a fait des trucs et c'est sûr c'est plus clean, c'est plus compréhensible, c'est plus joli, c'est plus "compliant", c'est plus compact et ça a fait avancer deux choses :
- Ma satisfaction personnelle concernant le code, mais ça on s'en fou un peu, puisque par définition "personnelle"
- Ça crash moins sous Windows en debug, voire parfois pas du tout, mais scientifiquement ce n'est pas acceptable

On peut toujours faire mieux concernant le code, c'est indéniable, et il doit y avoir des bugs là dedans, et même s'il n'y en a pas, ce serait être anti pro de le penser voir interdit de le croire.

Mais je ne comprends pas deux choses :

- Pourquoi ça a amélioré le truc en debug sous Windows, alors que fondamentalement rien n'a changé ?
- 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 ?

Loin de moi la non volonté de mettre à jour cette brique logicielle aux normes C++17 ou d'utiliser les conteneurs de la STL dès lors que ceux-ci ne dégradent pas les performances (c'est une brique traitant d'un sujet math / algo combinatoire). Pour le module node natif on n'hésite pas à utiliser des map / stack et vector, mais là on a juste besoin de tableaux.

Je peux changer aussi la notation hongroise des variables en japonais ou maya, mais je doute que ça fasse avancer le sujet pour autant.

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é ?

En tout cas merci pour ces échanges, c'est toujours constructif

Ta question actuelle, c'est bien "pouquoi c'est pas pareil dans des environnements différents?", n'est-ce pas?

Et bien la première réponse tout à fait pragmatique est: parce que tu utilises deux compilateurs distincts, pouvant tous deux avoir des écarts avec la norme.
En théorie, gcc avec une option --std=c++?? (11, 14 ou 17) serait respectueux de la norme au sens strict.

Concrêtement il y a aussi une autre réponse, beaucoup plus cartésienne: parce que quelque part dans ton code, tu utilises un "undefined behaviour" ou un "unspecified behaviour".
Ce sont des cas où, la norme n'exigeant pas de comportement spécifique, les compilateurs peuvent faire ce qu'ils veulent, et généralement, pas la même chose que les autres.

As-tu un warning avec gcc -Wall -Wextra? Si oui, ton code présente un problème.

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.

Merci pour vos réponses,

Je comprends tout à fait ce que vous dites, et je n'aime pas non plus ce genre de trucs, d'autant plus que j'en ai besoin, alors j'aime encore moins.

Comment puis-je sortir un "dump" sous Visual Studio en mode debug sous Windows ?

Merci encore,

A bientôt

L'utilisation des DUMPs, c'est quand vous avez des problèmes sur les machines de tests ou de production, ou que l'utilisation d'un débogueur attaché au processus complique l'affaire.
Si vous avez la "chance" d'avoir un plantage même avec un débogueur attaché au processus et que cela n'influence pas la vitesse d'arrivée du problème, autant utiliser directement le débogueur de VS.
Le débogueur l'endroit où ça par en cacahuète et pourquoi. Ce n'est pas forcement la cause initiale du rpoblème mais cela permet de mettre en place des tests pour valider des hypothèses bien plus étayés que le doigt mouillé.

Bref, quand ça plante, il dit quoi le débogueur ? :mouarf:

Le dump donne ça :

Citation:

---

Dump Summary
------------
Dump File: node.dmp : C:\Users\kin\Desktop\node.dmp
Last Write Time: 01/12/2017 19:29:17
Process Name: node.exe : C:\Program Files (x86)\nodejs\node.exe
Process Architecture: x86
Exception Code: 0xC0000005
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Heap Information: Present

System Information
------------------
OS Version: 6.1.7601
CLR Version(s):

Dump Summary
------------
Dump File: node.dmp : C:\Users\kin\Desktop\node.dmp
Last Write Time: 01/12/2017 19:29:17
Process Name: node.exe : C:\Program Files (x86)\nodejs\node.exe
Process Architecture: x86
Exception Code: 0xC0000005
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Heap Information: Present

System Information
------------------
OS Version: 6.1.7601
CLR Version(s):

Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
node.exe C:\Program Files (x86)\nodejs\node.exe 8.9.1.0
ntdll.dll C:\Windows\SysWOW64\ntdll.dll 6.1.7601.23915
kernel32.dll C:\Windows\SysWOW64\kernel32.dll 6.1.7601.23915
KERNELBASE.dll C:\Windows\SysWOW64\KERNELBASE.dll 6.1.7601.23915
ws2_32.dll C:\Windows\SysWOW64\ws2_32.dll 6.1.7601.23451
msvcrt.dll C:\Windows\SysWOW64\msvcrt.dll 7.0.7601.17744
rpcrt4.dll C:\Windows\SysWOW64\rpcrt4.dll 6.1.7601.23915
sspicli.dll C:\Windows\SysWOW64\sspicli.dll 6.1.7601.23915
CRYPTBASE.dll C:\Windows\SysWOW64\CRYPTBASE.dll 6.1.7601.23915
sechost.dll C:\Windows\SysWOW64\sechost.dll 6.1.7601.18869
nsi.dll C:\Windows\SysWOW64\nsi.dll 6.1.7601.23889
winmm.dll C:\Windows\System32\winmm.dll 6.1.7601.17514
user32.dll C:\Windows\SysWOW64\user32.dll 6.1.7601.23594
gdi32.dll C:\Windows\SysWOW64\gdi32.dll 6.1.7601.23914
lpk.dll C:\Windows\SysWOW64\lpk.dll 6.1.7601.23930
usp10.dll C:\Windows\SysWOW64\usp10.dll 1.626.7601.23894
advapi32.dll C:\Windows\SysWOW64\advapi32.dll 6.1.7601.23915
IPHLPAPI.DLL C:\Windows\System32\IPHLPAPI.DLL 6.1.7601.17514
winnsi.dll C:\Windows\System32\winnsi.dll 6.1.7601.23889
psapi.dll C:\Windows\SysWOW64\psapi.dll 6.1.7600.16385
userenv.dll C:\Windows\SysWOW64\userenv.dll 6.1.7601.17514
profapi.dll C:\Windows\SysWOW64\profapi.dll 6.1.7600.16385
imm32.dll C:\Windows\System32\imm32.dll 6.1.7601.17514
msctf.dll C:\Windows\SysWOW64\msctf.dll 6.1.7601.23915
api-ms-win-core-synch-l1-2-0.DLL C:\Windows\System32\api-ms-win-core-synch-l1-2-0.DLL 10.0.10586.1171
powrprof.dll C:\Windows\System32\powrprof.dll 6.1.7600.16385
setupapi.dll C:\Windows\SysWOW64\setupapi.dll 6.1.7601.17514
cfgmgr32.dll C:\Windows\SysWOW64\cfgmgr32.dll 6.1.7601.17621
oleaut32.dll C:\Windows\SysWOW64\oleaut32.dll 6.1.7601.23775
ole32.dll C:\Windows\SysWOW64\ole32.dll 6.1.7601.23889
devobj.dll C:\Windows\SysWOW64\devobj.dll 6.1.7601.17621
mswsock.dll C:\Windows\System32\mswsock.dll 6.1.7601.23451
WSHTCPIP.DLL C:\Windows\System32\WSHTCPIP.DLL 6.1.7600.16385
wship6.dll C:\Windows\System32\wship6.dll 6.1.7600.16385
cryptsp.dll C:\Windows\System32\cryptsp.dll 6.1.7601.23471
rsaenh.dll C:\Windows\System32\rsaenh.dll 6.1.7600.16385
pcwum.dll C:\Windows\System32\pcwum.dll 6.1.7600.16385
dnsapi.dll C:\Windows\System32\dnsapi.dll 6.1.7601.17570
dhcpcsvc6.DLL C:\Windows\System32\dhcpcsvc6.DLL 6.1.7601.17970
dhcpcsvc.dll C:\Windows\System32\dhcpcsvc.dll 6.1.7600.16385
nlaapi.dll C:\Windows\System32\nlaapi.dll 6.1.7601.18685
NapiNSP.dll C:\Windows\System32\NapiNSP.dll 6.1.7600.16385
pnrpnsp.dll C:\Windows\System32\pnrpnsp.dll 6.1.7600.16385
winrnr.dll C:\Windows\System32\winrnr.dll 6.1.7600.16385
NodeAlgo.node \\?\C:\dev\node-algo\node_modules\NodeAlgo_module\build\Release\NodeAlgo.node 0.0.0.0
nodegit.node \\?\C:\dev\node-algo\node_modules\nodegit\build\Release\nodegit.node 0.0.0.0
winhttp.dll C:\Windows\System32\winhttp.dll 6.1.7601.23451
webio.dll C:\Windows\System32\webio.dll 6.1.7601.23375
crypt32.dll C:\Windows\SysWOW64\crypt32.dll 6.1.7601.23769
msasn1.dll C:\Windows\SysWOW64\msasn1.dll 6.1.7601.17514
algo.dll C:\dev\algos\bin\Win32\Debug\algo.dll 0.0.0.0
MSVCP140D.dll C:\Windows\System32\MSVCP140D.dll 14.0.23026.0
VCRUNTIME140D.dll C:\Windows\System32\VCRUNTIME140D.dll 14.0.23026.0
ucrtbased.dll C:\Windows\System32\ucrtbased.dll 10.0.10150.0
api-ms-win-core-timezone-l1-1-0.dll C:\Windows\System32\api-ms-win-core-timezone-l1-1-0.dll 10.0.10586.1171
api-ms-win-core-file-l2-1-0.dll C:\Windows\System32\api-ms-win-core-file-l2-1-0.dll 10.0.10586.1171
api-ms-win-core-localization-l1-2-0.dll C:\Windows\System32\api-ms-win-core-localization-l1-2-0.dll 10.0.10586.1171
api-ms-win-core-processthreads-l1-1-1.dll C:\Windows\System32\api-ms-win-core-processthreads-l1-1-1.dll 10.0.10586.1171
api-ms-win-core-file-l1-2-0.dll C:\Windows\System32\api-ms-win-core-file-l1-2-0.dll 10.0.10586.1171

---

J'ai mis en gras ce dont j'ai la main, à savoir le module qui fait le lien entre NodeJS et ma DLL (compile avec node-gyp), ainsi que ma DLL.

Le débogueur pointe sur l'instanciation d'une classe sur la pile, sans rentrer dans son constructeur, comme si l'espace nécessaire à cette classe n'avait pu être alloué.

Code:

---

1 2 3

MaClasse maClasse; // <-- pointe ici, sans rentrer dans les traitements dans le constructeur maClasse.Load();

---

La partie "win" du binding.gyp :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

{ "libraries": [ "C:/dev/libs/jsoncpp/makefiles/msvc2010/Debug/lib_json.lib" ], "defines": [ "WIN32", "_MBCS", "NDEBUG" ], 'msvs_settings': { 'VCCLCompilerTool': { 'AdditionalOptions': [ '/MTd', ] } } }

---

Est-ce que vous voyez quelque chose qui vous saute aux yeux ?

Les traces montrent un mélange de Release et de Debug entre vos 2 modules.
Si l'API n'est pas strictement étanche d'un point de vu mémoire, ça le fera pas.

"NDEBUG" + "/MTd", heu faudrait savoir, c'est du DEBUG ou du RELEASE ???

Si le débugging ligne à ligne ne vous indique rien, pensez aussi à passer au niveau de l'assembleur.

Mouais... ça me gonfle.

Du coup j'y ai remis un serveur http dans la DLL, avec boost cette fois, au moins je maîtrise la plomberie pour y accéder, et ça fonctionne.

C'est con de devoir en arriver là, en 2017 mais bon.. c'est comme ça.

Citation:

---

C'est con de devoir en arriver là, en 2017 mais bon.. c'est comme ça.

---

Heu, je ne trouve pas que c'est un problème technique, on mélange pas les DEBUG et les RELEASE, c'est tout. 8O

Oui j'en conviens, mais ça me paraît étonnant quand même.

Admettons une application composée de plugins (des DLL ou .so) chargés dynamiquement, comment ils font les gens pour déboguer leur plugin en particulier ? Ils doivent recompiler également l'application et tous les plugins en DEBUG même lorsqu'ils ne communiquent pas entre eux ?

Parce que dans ce cas présent, l'applicatif NodeJS se comporte comme l'application et ma DLL comme un plugin parmi tant d'autres. Du coup tu es en train de me dire qu'il me faille recompiler NodeJS en debug ainsi que les modules dépendants de l'application et je n'aurai plus de problème ?

Je ne connais pas NodeJS, mais.

Alors votre analogie entre "application+plugIns" et "NodeJS+Votre Dll" est tout à fait pertinente.

Une architecture de plug-Ins soignée cloisonne les allocations entre l'application et les plug-Ins, mais il n'est pas rare, malheureusement, que l’étanchéité mémoire ne fasse pas partie des préceptes qui ont présidé à la conception de l'interface des plug-Ins.
Dans le tout, sans info sur cette interface, je prends le partie de ne pas me basé sur cette étanchéité putative.
Dans le cas de non-étanchéité, les concepteurs de l'application indiquent simplement les options de compilations nécessaires à un bon fonctionnement des plug-Ins dans leur application.

Il est tout à fait possible, bien qu'un peu moins confortable, de déboguer une compilation RELEASE, du moment que vous aillez pris la peine de configurer votre projet pour qu'il génère les fichiers .pdf même en RELEASE.
Faire une version DEBUG d'un exécutable Open Source n'est pas bien compliqué non plus.

Mais, et surtout, quand vous compilez votre Dll, vos options de compilation doivent être "cohérentes" :

Citation:

---

"NDEBUG" + "/MTd", heu faudrait savoir, c'est du DEBUG ou du RELEASE ???

---

En vous demandant d'utiliser la même version de C-Runtime que l'applicatif, c'est juste pour écarter un problème qui est la source de la très grande majorité de type de "Code: 0xC0000005" quand ce n'est pas juste un pointeur merdeux, l'utilisation de 2 C-Runtime dans une interface non étanche à l'allocation mémoire.

Citation:

---

Envoyé par mister3957

Admettons une application composée de plugins (des DLL ou .so) chargés dynamiquement, comment ils font les gens pour déboguer leur plugin en particulier ?

---

La réponse est simple ... mais pas applicable à tous les projets :mrgreen: : un plug-in/ une DLL/ une application c'est juste un "conteneur de services".

Il faut séparer son code en différentes parties (IHM, logique métier, ...) et pour les plus importantes, pouvoir les utiliser tout également avec des tests/ une ligne de commande/ une IHM simplifiée