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

Dotnet Discussion :

DLLimport C silent crash


Sujet :

Dotnet

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2006
    Messages : 82
    Points : 47
    Points
    47
    Par défaut DLLimport C silent crash
    Bonjour,
    Je dois utiliser une dll en C en .net. Je suis reparti d'un cas simple car je n'arrive pas à la faire fonctionner.
    J'ai compilé cette dll C en 32 bits avec mingw et configurer mon projet visual studio en 32 bits, là pas de soucis. Cela fonctionne. J'ai même les bonnes exceptions si la fonction n'est pas implémentée dans la lib et les bons résultats si elle l'est.
    Ensuite étant sur cygwin en 64 bits j'ai fait de même en configurant bien mon visual studio sur une cible 64. Mais là c'est aléatoire. Soit ça marche impeccable. Soit ça crashe sans aucune exception, il se ferme juste. Et genre je la relance 5 ou 6 fois où ça crash et une fois ça va marcher... puis de nouveau plus rien. Je ne change absolument rien entre temps...

    Si quelqu'un a des pistes car je ne sais pas du tout où regarder. Merci

    Mon code C :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <windows.h>
     
     
    __declspec(dllexport) int somme(int a, int b)
    {
        return a * b + 900;
    }
    Mon code vb.net

    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
    17
    18
    19
    20
    Imports System
    Imports System.Runtime.InteropServices
     
    Public Class Form1
     
        <DllImport("C:\TEMP\delete\prog\Test_DLL2\bin\Debug\startup.dll", CallingConvention:=CallingConvention.StdCall, CharSet:=CharSet.None)>
        Public Shared Function somme(ByVal a As Integer, ByVal b As Integer) As Integer
        End Function
     
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            Try
                Dim res As Integer = somme(7, 4)
                TextBox1.Text = res
            Catch ex As Exception
                TextBox1.Text = ex.Message
            End Try
     
        End Sub
     
    End Class

  2. #2
    Membre du Club
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2006
    Messages : 82
    Points : 47
    Points
    47
    Par défaut
    En cochant dans visual studio permettre le debuggage natif j'ai une exception au moment d'appeler somme:
    Violation d'accès à l'emplacement
    Je ne sais pas si c'est une bonne piste mais bon...

  3. #3
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2016
    Messages
    2 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2 761
    Points : 10 546
    Points
    10 546
    Billets dans le blog
    21
    Par défaut
    La gestion des types de base comme "int" diffère en .Net et en C :
    - en .Net : un int = Int32 et sera toujours sur 4 octets, indépendemment de l'architecture
    - en C : un int est un mot machine. Typiquement, 4 octets sur une architecture 32 bits et 8 octets sur une architecture 64 bits.

    En 32 bits, pas de souci, tout est de la même taille. Par contre, en 64 bits, la taille d'un entier n'est certainement pas la même entre le code en C et le code VB.Net. Cela résulte en une corruption de la pile générant aléatoirement des erreurs.

    Soit il faut changer le code VB.Net pour utiliser des long, soit il faut changer le code C pour utiliser int32_t

  4. #4
    Membre du Club
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2006
    Messages : 82
    Points : 47
    Points
    47
    Par défaut
    Bonjour, merci de votre réponse. Oui j'avais exploré cette piste mais sans meilleur résultat.
    J'ai quand même réesayer dans les 2 sens. En changeant le C, pas mieux, puis en changeant le vb.net, pas mieux.
    J'en suis venu même à mettre juste une fonction qui n'a pas de paramètres:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    #include <windows.h>
     
    __declspec(dllexport) void setme()
    {
        ;
    }
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
        <DllImport("C:\TEMP\delete\prog\Test_DLL2\bin\Debug\startup.dll", CallingConvention:=CallingConvention.Cdecl, CharSet:=CharSet.None)> _
        Public Shared Sub setme()
        End Sub
    Et j'ai toujours cette erreur

    Exception non gérée à 0x00007ffcebef90a2 dans WindowsApplication9.exe*: 0xC0000005: Violation d'accès lors de l'écriture à l'emplacement 0x00000003bfa00ff8.

  5. #5
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2016
    Messages
    2 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2 761
    Points : 10 546
    Points
    10 546
    Billets dans le blog
    21
    Par défaut
    Une raison particulière pour que la convention soit initialisée à CDECL ? De mémoire, c'est plutôt STDCALL par défaut. Bon, par contre, cela ne devrait pas influencer une fonction sans paramètres...

    comment est compilé le programme C ? Avec quelle ligne de commande ?

  6. #6
    Membre du Club
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2006
    Messages : 82
    Points : 47
    Points
    47
    Par défaut
    Non pas de raison particulière, j'ai fouillé pas mal sur internet pour ça et j'ai essayé celui ci en dernier.
    Pour compiler j'avais trouvé ces commandes peut etre mal adaptées ?! :

    gcc -std=gnu99 -g -c -O -O -mms-bitfields -Wall -Wno-unused startup.c
    gcc -shared -o startup.dll startup.o

  7. #7
    Membre du Club
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2006
    Messages : 82
    Points : 47
    Points
    47
    Par défaut
    j'ai essayé diverses options de compilation de gcc, pas mieux non plus... des pistes ?

  8. #8
    Membre du Club
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2006
    Messages : 82
    Points : 47
    Points
    47
    Par défaut
    Bon, cela vient de la compilation avec cygwin64. Quand j'utilise sa commande gcc, ça ne marche pas. J'ai essayé avec celle de gnat-pro que j'avais sur mon pc et là aucun soucis...
    Je ne comprends pas pourquoi sur cygwin64 ne fonctionne pas... Ce n'est pas la même version de gcc. donc celle de cygwin semble poser probleme.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. STL::vector crash a l"execution
    Par sebA dans le forum MFC
    Réponses: 2
    Dernier message: 16/06/2004, 17h36
  2. Crash de mon dvd encrypté avec xine
    Par Slein dans le forum Applications et environnements graphiques
    Réponses: 3
    Dernier message: 06/06/2004, 17h45
  3. [IB6] mon serveur crash apres des insert en série...
    Par Rmotte dans le forum Débuter
    Réponses: 11
    Dernier message: 27/05/2004, 15h53
  4. DLL Borland chargée par Windows: crash
    Par bocher dans le forum C++Builder
    Réponses: 2
    Dernier message: 08/01/2004, 13h09
  5. Crash Base Access
    Par Ronald G. dans le forum Access
    Réponses: 4
    Dernier message: 04/08/2003, 12h55

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