COM Creation & Crashing Issue

This is a discussion on COM Creation & Crashing Issue within the Windows Programming forums, part of the Platform Specific Boards category; I have read some tutorials on creating COM objects using Visual C++ 2003. I am getting some errors though (expected). ...

  1. #1
    Software engineer
    Join Date
    Aug 2005
    Location
    Oregon
    Posts
    283

    COM Creation & Crashing Issue

    I have read some tutorials on creating COM objects using Visual C++ 2003. I am getting some errors though (expected). Say I threw in a .lib file, the .h file, and the dll in the debug folder. For example, there are two static member methods in the class X3D::Util. This line runs well...

    X3D::Util::ClearLog();

    However, say X3D::Util::Log in a if-condition, the program crashes. Does this have anything to do with the COM object being static? Why does the first once succeed?

    The output window reads:
    HEAP[T3D Console.exe]: Invalid Address specified to RtlValidateHeap( 00860000, 00883CC0 )
    Unhandled exception at 0x7c901230 in T3D Console.exe: User breakpoint.

    A user breakpoint is presented in the file dbgheap.c.

    This COM object worked fine in a small console program. When I put it into my Windows application, it just started causing this issue. Could it have anything to do with the way this DLL was compiled with this code? I can only think each member is static so the class is never really allocated globally, but its just used on the spot when needed (each member is static), so making an object of it doesn't make much sense.

    Side note too: Sometimes it works just fine. Other times it doesn't. In this case, if X3D::Util::Log() is in a if-block, it freaks out. Put this outside of the if-block, and it works just fine.

    Is there something I'm missing?

    COM .h file:
    Code:
    #ifndef _X3DUTIL_H_ 
    #define _X3DUTIL_H_ 
    
    #include <iostream> 
    #include <fstream> 
    #include <string> 
    #include <windows.h> 
    
    namespace X3D 
    { 
       class __declspec(dllexport) Util 
       { 
       public:  
          static bool Log(std::string debugText, std::string filepath = "log.txt"); 
          static bool ClearLog(std::string filepath = "log.txt"); 
       }; 
    } 
    
    #endif
    COM .cpp file:
    Code:
    #include "X3DUtil.h" 
      
    bool X3D::Util::Log(std::string debugText, std::string file) 
    { 
       std::ofstream out(file.c_str(), std::ios::out | std::ios::app); 
       if (!out.is_open()) 
          return false; 
    
       out << debugText << std::endl; 
       out.close(); 
    
       return true; 
    } 
      
    bool X3D::Util::ClearLog(std::string file) 
    { 
       std::ofstream out(file.c_str(), std::ios::out); 
       if (!out.is_open()) 
          return false; 
    
       out.close(); 
    
       return true; 
    }
    Last edited by dxfoo; 02-18-2008 at 06:15 PM.

  2. #2
    Software engineer
    Join Date
    Aug 2005
    Location
    Oregon
    Posts
    283
    This is really odd...

    // intentional to go in block for example
    if (RegisterClassEx(&wc)) {
    X3D::Util::Log("Message.");
    return 1;
    }

    Works fine. Now put two or three words in the string and BAM! Error.
    Last edited by dxfoo; 02-18-2008 at 08:34 PM.

  3. #3
    Software engineer
    Join Date
    Aug 2005
    Location
    Oregon
    Posts
    283
    How's this for brilliant? I got rid of the C++ code in the Log function and everything is working now. I just used the origional fopen(), fclose(), etc. and it worked. C++ can be daunting sometimes. I'd like to know exactly what went wrong though.

  4. #4
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,662
    What you've you shown isn't really a COM object - it's just a class object implemented in a DLL.

    Couple things. You should use __declspec(dllexport) when building the DLL, and __declspec(dllimport) when the client application includes the header file. Easiest way to do this is with a macro in the header:
    Code:
    #ifdef MY_DLL_BUILD
    #   define MY_DLL_API  __declspec(dllexport)
    #else
    #   define MY_DLL_API  __declspec(dllimport)
    #endif
    
    class MY_DLL_API MyClass {...}
    The other thing is that you should avoid passing CRT objects from one module (dll/exe) to another. This includes things like std::string. So a safer API for your string parameters would be to use "const char*".

    http://msdn2.microsoft.com/en-us/lib...60(VS.80).aspx

    gg

  5. #5
    Software engineer
    Join Date
    Aug 2005
    Location
    Oregon
    Posts
    283
    Thanks for the response. It sounds like there's a lot of do's and don'ts in this type of project, but I guess that's true with anything. Can you tell me when it's okay to use C++ code in a DLL project? I'm assuming its a no when passing parameters like std::string, but in the body of the function it is fine?

  6. #6
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,662
    You can do what you want in the body of the function. Just use simple types for parameters and for any member variables of classes you expose.

    gg

  7. #7
    Software engineer
    Join Date
    Aug 2005
    Location
    Oregon
    Posts
    283
    Thanks for clarifying. I'm curious though why this rule exists though. Is it a bug, feature, or just how DLL/EXE's work in C/C++ programs?

  8. #8
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,662
    Well, it's more of a "rule of thumb".

    In your case, suppose a user of your DLL decides they want to use the STLport library instead of the STL implementation which was used to compile your DLL.

    If both the client and DLL are built against the same runtime DLL (not static), then you could pass around std::string's and other CRT objects. It's just dangerous.

    gg

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Strange windows STL crashing problem
    By kdmiller in forum C++ Programming
    Replies: 5
    Last Post: 06-23-2010, 02:25 PM
  2. float calculation issue
    By George2 in forum C# Programming
    Replies: 1
    Last Post: 05-26-2008, 04:56 AM
  3. type safe issue
    By George2 in forum C++ Programming
    Replies: 4
    Last Post: 02-12-2008, 08:32 PM
  4. Newton + Einstein were wrong!
    By Jez in forum A Brief History of Cprogramming.com
    Replies: 64
    Last Post: 12-14-2004, 01:24 PM
  5. my first issue of GDM
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 0
    Last Post: 09-12-2002, 04:02 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21