0

I'm compiling a 3rd party code (which is given as a VS solution) to a static library. This code has one class which is for simplification looks like this:

Sample.h:

class Sample
{
 public:
    Sample();
    ~Sample();
    void Foo();
 private:
    // some private members.
};

Sample.cpp:

Sample::Sample()
{
}
Sample::~Sample()
{
}
void Sample::Foo()
{
    //Do something...
}

This class compiles to a static library Sample.lib

Now in my main program I want to initiate an object of Sample:

MyFile.cpp:

#include "Sample.h"
//some code.
Sample* sample = new Sample();
//some code

and at some point when the program continues I'm getting a crash. The place where it crashes isn't consistent:

Unhandled exception at 0x770A0BFE (ntdll.dll) in MyApplication.exe: 0xC0000005: Access violation reading location 0xFFFFFFF8.

But when I put the Sample class in a wrapper class (in the same solution of the static lib): Wrapper.cpp:

class Wrapper
{
public:
    Wrapper()
    {
        _sample = new Sample();
    }
    ~Wrapper()
    {
        delete sample;
    }
    void Foo()
    {
       _sample->Foo();
    }
private:
    Sample* _sample;
}

and then initialize the Wrapper class in my program:

MyFile.cpp:

#include Sample.h
//some code.
Wrapper* wrapper = new Wrapper();
//some code

It works well and I'm not getting any crash.

Does anybody has a clue? Thanks!

Sanich
  • 1,739
  • 6
  • 25
  • 43
  • Are you attempting to instantiate the class in the static library code or in the application code? –  Feb 25 '17 at 23:13
  • *"at some point I'm getting a crash"* - That's interesting, but not very helpful. Why don't you break into the debugger? You'll immediately see the call stack, which is missing from this question. You also failed to describe, what a *"crash"* is to you. A debug assertion? An SEH exception? Something else? – IInspectable Feb 25 '17 at 23:18
  • @NeilButterworth in the application code which is in another solution. – Sanich Feb 25 '17 at 23:19
  • @IInspectable the thing is that it is not consistent. Each time the call stack is something else. I'm gussing that there is some memory corruption so at some point it crashes – Sanich Feb 25 '17 at 23:27
  • @NeilButterworth BTW, if I take the wrapper code to my application solution I'll get the crash as well – Sanich Feb 25 '17 at 23:33
  • Post the full text of the crash report you are getting. –  Feb 25 '17 at 23:34
  • @NeilButterworth I added it to the question. Thanks! – Sanich Feb 25 '17 at 23:44
  • 1
    OK, you have some sort of invalid pointer somewhere in your code. Unfortunately, it is almost certainly _not_ in the code you have posted - that code is simply exposing the problem. I'm afraid this is a problem only you can solve, by debugging your code. –  Feb 25 '17 at 23:48
  • @NeilButterworth I thinks that it might be related to some alignment optimization which is inconsistent between the two solution. But I cant find it – Sanich Feb 25 '17 at 23:51
  • Probably not. And if you are debugging, turn off all optimisations. –  Feb 25 '17 at 23:53
  • This has nothing to do with alignment. You are dereferencing a `nullptr`. And since the program then tries to read memory towards lower addresses, it is pretty safe to say, that this is the memory manager of your runtime. At a guess I'm going to assume, that your static library is linked against a runtime that's incompatible with the one that's trying to destroy the object. – IInspectable Feb 26 '17 at 01:35
  • @IInspectable. In both solutions it is `Multi-threaded Debug (/MTd)`. I've made all options to be identical but it didn't help. – Sanich Feb 26 '17 at 08:49
  • That means you have multiple copies of the CRT linked into your application. That can't be good. Use `/MD` (and `/MDd`) instead. – IInspectable Feb 26 '17 at 10:38
  • @IInspectable Why there are multiple copies? 3rd party code is a static lib so the linkage should be when I compile my application. And if you are right, how should I use static libs if I do want (and I do) to use MT (I can't use MD). – Sanich Feb 26 '17 at 11:59

0 Answers0