IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

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


Sujet :

C++

  1. #21
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    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.
    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.
    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!

    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 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.
    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...
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  2. #22
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    Configurez la production pour générer un DUMP lors d'un crash et analysez ce DUMP pour voir le motif du crash.

  3. #23
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    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.
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  4. #24
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    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:
    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é ), 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

    Commences par faire quelque chose qui fonctionne correctement NDD! tu feras quelque chose de rapide par la suite
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  5. #25
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    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
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  6. #26
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 186
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 186
    Points : 17 126
    Points
    17 126
    Par défaut
    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.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  7. #27
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    Je trouve vos assertions très cavalières.

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

    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.

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

    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.

    - 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 !!!

    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.

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

    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.

  8. #28
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    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
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  9. #29
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    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 ?

  10. #30
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    Le dump donne ça :

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    MaClasse maClasse; // <-- pointe ici, sans rentrer dans les traitements dans le constructeur
    maClasse.Load();
    La partie "win" du binding.gyp :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 ?
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  11. #31
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    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.

  12. #32
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    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.
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  13. #33
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    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.

  14. #34
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    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 ?
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  15. #35
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    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" :
    "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.

  16. #36
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 551
    Points
    10 551
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    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 : 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

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. TTimer dans une dll utilisée par une application .net
    Par Pascale38 dans le forum C++Builder
    Réponses: 16
    Dernier message: 12/07/2017, 17h18
  2. Réponses: 4
    Dernier message: 02/12/2011, 15h52
  3. Réponses: 0
    Dernier message: 15/04/2010, 13h34
  4. Réponses: 3
    Dernier message: 03/09/2008, 16h09
  5. Utilisation d'une dll native par une toolbar managée
    Par didierll dans le forum C++/CLI
    Réponses: 1
    Dernier message: 10/07/2007, 08h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo