Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Release <-> Debug woes

Release <-> Debug woes

Scheduled Pinned Locked Moved C / C++ / MFC
c++debugginghelpannouncement
6 Posts 2 Posters 1 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P Offline
    P Offline
    Phil Benson
    wrote on last edited by
    #1

    Hi I have the following problem: I have an executable that loads dlls (MFC extension dll´s). All the dll´s are based on a parent class with various functions. To name a few BOOL mfb_open_database (LPCTSTR); CString mfx_get_module_name(); CString mfx_get_item_text (LPVOID); The functions are called from the main application using a pointer to the dll class.. x_txt = px_dll->mfx_get_item_text((LPVOID)something); The functions in the dll´s are all with AFX_MANAGE_STATE(..) because I´m loading things from the (DLL´s) resources The funny thing is only the mfx_get_module_name() does not work, all the others do. Tracing through this (I have added the debug symbols to the release mode of a dll and the exe) It comes about when the constructors for the CString objects are called. As far as I can tell, the DLL creates a CString object to be returned. Instead of a "Deep" copy, only the reference of it´s m_pchData is copied to the CString Object in the exe, and when the destructor for the CString Object in the exe is called, the MFC crashes and says that the Object that is to be destroyed is not in the "correct" heap. I have tried adding ::LockBuffer() to the CString object that is created in the DLL as the returned object but to no avail. I have checked all the project settings etc. and can´t find anything wrong. This function worked perfectly well up until yesterday, until my devstudio crashed a few times. I´ve checked all the settings in Project setings but can´t find anything un toward. Has anybody any idea´s I´m at my wits end.... Thanks in advance Phil bum... and I thought I´d got rid of all the bugs :(

    Who the F*** is general failure and why is he reading my hard drive?

    W P 2 Replies Last reply
    0
    • P Phil Benson

      Hi I have the following problem: I have an executable that loads dlls (MFC extension dll´s). All the dll´s are based on a parent class with various functions. To name a few BOOL mfb_open_database (LPCTSTR); CString mfx_get_module_name(); CString mfx_get_item_text (LPVOID); The functions are called from the main application using a pointer to the dll class.. x_txt = px_dll->mfx_get_item_text((LPVOID)something); The functions in the dll´s are all with AFX_MANAGE_STATE(..) because I´m loading things from the (DLL´s) resources The funny thing is only the mfx_get_module_name() does not work, all the others do. Tracing through this (I have added the debug symbols to the release mode of a dll and the exe) It comes about when the constructors for the CString objects are called. As far as I can tell, the DLL creates a CString object to be returned. Instead of a "Deep" copy, only the reference of it´s m_pchData is copied to the CString Object in the exe, and when the destructor for the CString Object in the exe is called, the MFC crashes and says that the Object that is to be destroyed is not in the "correct" heap. I have tried adding ::LockBuffer() to the CString object that is created in the DLL as the returned object but to no avail. I have checked all the project settings etc. and can´t find anything wrong. This function worked perfectly well up until yesterday, until my devstudio crashed a few times. I´ve checked all the settings in Project setings but can´t find anything un toward. Has anybody any idea´s I´m at my wits end.... Thanks in advance Phil bum... and I thought I´d got rid of all the bugs :(

      W Offline
      W Offline
      wb
      wrote on last edited by
      #2

      are the dlls AND the app the same build type?? Release or Debug? I spent some days on a realy anoying bug. My App was Release Build and the DLL was Debugbuild and it crashes all the time!! solution-> use the same build type.

      P 1 Reply Last reply
      0
      • W wb

        are the dlls AND the app the same build type?? Release or Debug? I spent some days on a realy anoying bug. My App was Release Build and the DLL was Debugbuild and it crashes all the time!! solution-> use the same build type.

        P Offline
        P Offline
        Phil Benson
        wrote on last edited by
        #3

        Yes, same build type. The really stupid thing is, that before the DevStudio crash everything worked fine :confused: bum... and I thought I´d got rid of all the bugs :(

        Who the F*** is general failure and why is he reading my hard drive?

        W 1 Reply Last reply
        0
        • P Phil Benson

          Yes, same build type. The really stupid thing is, that before the DevStudio crash everything worked fine :confused: bum... and I thought I´d got rid of all the bugs :(

          W Offline
          W Offline
          wb
          wrote on last edited by
          #4

          sure? I also thought all the time, my DLLs and the App are the same build, BUT somewhere deep was a silly path to the wrong directory with the wrong DLLs. :( don't know other reason.. sory.

          P 1 Reply Last reply
          0
          • W wb

            sure? I also thought all the time, my DLLs and the App are the same build, BUT somewhere deep was a silly path to the wrong directory with the wrong DLLs. :( don't know other reason.. sory.

            P Offline
            P Offline
            Phil Benson
            wrote on last edited by
            #5

            Yes I´ve checked.. I´ll have another look at the settings in a text editor, but in the IDE everything seems to be ok. And thanks for helping... Phil bum... and I thought I´d got rid of all the bugs :(

            Who the F*** is general failure and why is he reading my hard drive?

            1 Reply Last reply
            0
            • P Phil Benson

              Hi I have the following problem: I have an executable that loads dlls (MFC extension dll´s). All the dll´s are based on a parent class with various functions. To name a few BOOL mfb_open_database (LPCTSTR); CString mfx_get_module_name(); CString mfx_get_item_text (LPVOID); The functions are called from the main application using a pointer to the dll class.. x_txt = px_dll->mfx_get_item_text((LPVOID)something); The functions in the dll´s are all with AFX_MANAGE_STATE(..) because I´m loading things from the (DLL´s) resources The funny thing is only the mfx_get_module_name() does not work, all the others do. Tracing through this (I have added the debug symbols to the release mode of a dll and the exe) It comes about when the constructors for the CString objects are called. As far as I can tell, the DLL creates a CString object to be returned. Instead of a "Deep" copy, only the reference of it´s m_pchData is copied to the CString Object in the exe, and when the destructor for the CString Object in the exe is called, the MFC crashes and says that the Object that is to be destroyed is not in the "correct" heap. I have tried adding ::LockBuffer() to the CString object that is created in the DLL as the returned object but to no avail. I have checked all the project settings etc. and can´t find anything wrong. This function worked perfectly well up until yesterday, until my devstudio crashed a few times. I´ve checked all the settings in Project setings but can´t find anything un toward. Has anybody any idea´s I´m at my wits end.... Thanks in advance Phil bum... and I thought I´d got rid of all the bugs :(

              P Offline
              P Offline
              Phil Benson
              wrote on last edited by
              #6

              I have finally found the problem. In one of my base classes I have over written the OnDraw() and OnEraseBkgnd() to draw a custom background. Instead of using the MFC message entry macro, ON_WM_ERASEBKGND(), ON_WM_PAINT(), I used the API one: ON_MESSAGE(WM_PAINT, ...) etc. This all worked fine in debug mode, but crashed in release. Now everything works fine bum... and I thought I´d got rid of all the bugs :(

              Who the F*** is general failure and why is he reading my hard drive?

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


              • Login

              • Don't have an account? Register

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • World
              • Users
              • Groups