web-dev-qa-db-fra.com

Le point d'arrêt ne sera pas touché actuellement. Aucun code exécutable associé à cette ligne

J'ai un cours dans un fichier .h:

class Blah
{
public:
    Blah(){}
    virtual ~Blah(){}

    void WriteMessage( bool MessageReceived )
    {
        if(MessageReceived)
        {
            cout << "Message Recieved\n";
        }
    }
};

J'essayais de comprendre pourquoi mon code ne fonctionnait pas, alors j'ai défini un point d'arrêt sur la condition dans la fonction WriteMessage(), mais dès que j'ai commencé à exécuter le projet en mode débogage, le point d'arrêt s'estompait et l'info-bulle correspondante était ainsi affichée:

Le point d'arrêt ne sera pas touché actuellement.
Aucun code exécutable associé à cette ligne.

Je ne sais pas du tout pourquoi, car toutes mes autres fonctions membres pour d'autres classes fonctionnent parfaitement lorsqu'elles sont implémentées dans le fichier .h. Qu'est-ce qui cause ça?

Edit: Ok comme demandé, voici une version réduite du code réel avec lequel je travaille:

VimbaBridgeAPI.h (fichier d'en-tête pour .dll)

#pragma once

#ifdef VIMBABRIDGEAPI_EXPORTS
#define VIMBABRIDGEAPI_API __declspec(dllexport)
#else
#define VIMBABRIDGEAPI_API __declspec(dllimport)
#endif

#include "AlCamIncludes.h"
#include "VimbaSystem.h"

////////////////////////////////////////////
//  Global Variables ///////////////////////
////////////////////////////////////////////
extern HBITMAP hbit;
extern CEdit* global_filenamehandle;

////////////////////////////////////////////
//  Global Flags ///////////////////////////
////////////////////////////////////////////
extern bool imageReady;
extern bool take_picture;

using namespace AVT::VmbAPI;

VIMBABRIDGEAPI_API void BridgedGetImage(FramePtr framepoint, VmbUchar_t** imgDat);

VIMBABRIDGEAPI_API HBITMAP ExternalFrameRecieved( const FramePtr pFrame );

//////////////////////////////////////////////////////////////////////////
//////////  MyObserver class   ///////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////
class VIMBABRIDGEAPI_API MyObserver : public IFrameObserver
{
private:
    MyObserver( MyObserver& );

    MyObserver& operator=( const MyObserver& );

    //class member variables
    //BITMAPINFO*             pbmi;
    CEdit*                  m_filenameedit;

public:

    MyObserver(CameraPtr pCamera) : IFrameObserver(pCamera) {}
    virtual ~MyObserver() {}

    void FrameReceived ( const FramePtr pFrame );
};

REMARQUE: IFrameObserver n'est pas écrit par moi, mais la fonction FrameReceived est un virtuel pur déclaré dans la classe IFrameObserver. Leur documentation indique que FrameRecieved est appelé par leur API chaque fois qu'un cadre arrive et que je devais implémenter la fonction. J'ai testé ces fonctions et cela fonctionne, mais seulement lorsqu'elles sont définies en dehors de la classe (je reçois l'erreur que je reçois maintenant)

VimbaBridgeAPI.cpp (code caché à l'utilisateur)

void FrameRecieved( const FramePtr pFrame )
{
    DbgMsg(L"Frame Received\n");

    ////////////////////////////////////////////////////////////////////////
    //////////  Setup Bitmap  ////////////////////////////////////////////////
    //////////////////////////////////////////////////////////////////////////

    //// FILEHEADER ////
    BITMAPFILEHEADER* bf = new BITMAPFILEHEADER;
    bf->bfType = 0x4d42;
    bf->bfSize = 6054400 + 54 + sizeof(BITMAPINFO);
    bf->bfOffBits = 54;

    //// INFOHEADER ////
    BITMAPINFOHEADER* bih = new BITMAPINFOHEADER;
    bih->biSize = 40;
    bih->biWidth = 2752;
    bih->biHeight = -2200;
    bih->biPlanes = 1;
    bih->biBitCount = 32;
    bih->biCompression = 0;
    //bi->biSizeImage = 6054400; //not required
    bih->biXPelsPerMeter = 2835;
    bih->biYPelsPerMeter = 2835;
    bih->biClrUsed = 0;
    bih->biClrImportant = 0;

    //// INFO ////
    BITMAPINFO* pbmi = (BITMAPINFO*)alloca( sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD)*256);
    pbmi->bmiHeader.biSize = sizeof (pbmi->bmiHeader);
    pbmi->bmiHeader.biWidth = 2752;
    pbmi->bmiHeader.biHeight = -2200;
    pbmi->bmiHeader.biPlanes = 1;
    pbmi->bmiHeader.biBitCount = 8;
    pbmi->bmiHeader.biCompression = BI_RGB;
    pbmi->bmiHeader.biSizeImage = 0;
    pbmi->bmiHeader.biXPelsPerMeter = 14173;
    pbmi->bmiHeader.biYPelsPerMeter = 14173;
    pbmi->bmiHeader.biClrUsed = 0;
    pbmi->bmiHeader.biClrImportant = 0;

    //create grayscale color palette
    for(int i=0; i<256; i++)
    {
        pbmi->bmiColors[i].rgbRed = BYTE(i);
        pbmi->bmiColors[i].rgbGreen = BYTE(i);
        pbmi->bmiColors[i].rgbBlue = BYTE(i);
        pbmi->bmiColors[i].rgbReserved = BYTE(0);
    }

    //// IMAGE DATA ////
    VmbUchar_t* imageData = NULL;
    BridgedGetImage(pFrame, &imageData);

    //////////////////////////////////////////////////////////////////////////
    ////// Create image that's printed to dialog box /////////////////////////
    //////////////////////////////////////////////////////////////////////////
    HDC hdc = ::GetDC(NULL);  
    hbit = CreateDIBitmap(hdc, bih, CBM_INIT, imageData, pbmi, DIB_RGB_COLORS);

    //clean up
    DeleteObject(bf);
    DeleteObject(bih);
    DeleteObject(hdc);
}
c++windowsvisual-studio-2010classdebugging
12
xcdemon05

Je vous suggérerais tout d’abord Supprimez les fichiers de sortie : Supprimez physiquement toutes les DLL, PDB et EXE générés. Puis compilez (reconstruisez) à nouveau pour générer les fichiers. Parfois, Visual Studio peut "se perdre" et "oublier" pour écraser les fichiers de sortie lorsque vous générez votre solution.

Cela peut arriver pour plusieurs autres raisons:

  • Le code utilisé par le débogueur est différent du code exécuté par l'application
  • Le fichier pdb utilisé par le débogueur est différent du code exécuté par l'application
  • Le code que l'application est en cours d'exécution a été optimisé et les informations de débogage ont été supprimées.
  • Le code dans lequel vous avez des points d'arrêt n'a pas encore été chargé dans le processus 
9
swaps

Je me suis retrouvé avec ce problème aussi, le contexte de mon application était une application principale en C # qui utilisait du code C++ non géré dans une couche inférieure dans laquelle je voulais entrer à partir du débogueur. À partir des propriétés du projet C #, je suis allé dans l'onglet Débogage et sous la section Activer les débogueurs, cochez la case "Activer le débogage de code non géré".

C# Project Properties Debug Tab

7
jxramos

Je voulais mentionner que j'ai rencontré l'erreur "Breakpoint will not be hit..." lors du portage de certains de mes anciens projets MFC (managed--using clr support) dans VS2015.

Ce qui a résolu le problème pour moi, c'est de régler ceci:

Configuration Properties\Linker\Debugging\Debuggable Assembly

... pour ça:

Yes (/ASSEMBLYDEBUG)

6
IVSoftware

Je voulais aussi ajouter ma propre solution. J'avais un projet C++ chargeant une DLL composée de code C++/CLR. Il s'est avéré que je devais définir le type de débogueur du projet de démarrage sur "Mixte". "Auto" ne détectait pas qu'elle nécessitait un support géré car la dll était chargée manuellement après le démarrage du programme.

2
Phillip

J'avais le même problème mais la solution acceptée de nettoyage des fichiers ne fonctionnait pas pour moi. J'ai résolu mon problème et cela avait à voir avec mon code. Voici les détails de mon correctif. J'espère que cela vous donnera des indices sur votre correctif.

Ce que je faisais, c'est de surcharger l'opérateur CArchive<< pour ma structure, mais le code n'y pénètre jamais. Je fixais le point de rupture et le symbole rouge était plein. Dès que je lance le débogueur, le symbole apparaît et le message d'avertissement s'affiche:

Le point d'arrêt ne sera pas touché actuellement. aucun code exécutable n'est associé à cette ligne

Mon code pertinent est ci-dessous où le point de rupture ne se brise pas. 

class Book
{
     friend CArchive& operator << (CArchive& ar, const Book & book )
     {

         ar << book.title;
         ar << "\r\n";
         ar << book.price;
         ar << "\r\n";
     }
}

Maintenant, il y a un problème évident avec ce code, c'est qu'il n'a pas d'instruction de retour return ar mais le compilateur ne s'est jamais plaint. La raison pour laquelle le compilateur ne s'est pas plaint était que j'utilisais l'opérateur de manière incorrecte (et ne l'utilisais jamais)

book *mybook = new Book(...);
ar << mybook;

Parce que j'accède par erreur à l'opérateur via un pointeur, l'opérateur << de mon objet n'a jamais été réellement invoqué et c'est pourquoi le compilateur ne s'est pas plaint non plus parce qu'il n'a jamais été utilisé. 

Alors d'abord j'ai corrigé le code d'appel

book *mybook = new Book(...);
ar << *mybook;

Maintenant, la méthode de surcharge de l'opérateur se plaint de l'instruction return et j'ai corrigé cela aussi.

Je peux maintenant entrer dans la fonction. Le point essentiel était donc que le point d'arrêt n'était pas défini car ce code était essentiellement mis à l'écart par le compilateur (correctement) car il n'avait jamais été utilisé dans le code.

0
zar