Why does compiling in -O2 crash my application but -O2 -fno-default-inline does not?

Question

I have a 3rd party lib called TheLib and my lib called MyLib

TheLib is compiled first with a Struct contained in a header file called variantmap.h. This header contains 2 inline functions:

struct VariantMap {
    string name;
    map<string, Variant> children;
    bool isArray;

    VariantMap(VariantMap & variantMap) {
        name = variantMap.name;
        children = variantMap.children;
        isArray = variantMap.isArray;
    }

    VariantMap() {
        isArray = false;
    }
};

MyLib also compiles with the aforementioned header.

When I compile both libs with -O2 (optimization level) MyLib crashes, but if I compile MyLib with -O2 but without inline functions (i.e. -fno-default-inline), it does not???

The crash seems to occur on the assignment of the string name according to gdb?

Answer 1

Are you using the same versions of the C-Run-time in everything? Some compiler suites add debug only information to header files (such as for example). If "TheLib" is compiled with the DEBUG pre-processor flag and you are compiling without, for example, then mismatches occur. It may just be random that it crashes there. Have you made sure that the data is correct the way that doesn't crash?

Answer 2

This is not a good copy constructor:

  VariantMap(VariantMap & variantMap) {
        name = variantMap.name;
        children = variantMap.children;
        isArray = variantMap.isArray;
  }

Firstly, it does nothing the default copy constructor wouldn't do better, and secondly it does not have a const reference asa parameter. Also, as you provided a copy constructor, presumably you have an assignment op and a destructor too? What do they look like? And lastly, is Variant (not VariantMap) really copyable? Remember, the point the error appears to be at is usually just the place it manifests itself.

Answer 3

I'm not knowledgable of this problem on Linux (not enough experience on g++), but on Windows, it smells of incompatible runtimes mixed together, so I guess my answer could give you some limited insight...

At first guess, it could be because TheLib and MyLib have different implementation of the same functions.

If the "copy constructor" is inlined "into" your MyLib, then the code will use MyLib's compiled implementation of the copy constructor's code (i.e. the string assignment).

In the other hand, if the call to the copy constructor is not "inlined", then perhaps the call to the copy constructor will call the code compiled inside TheLib.

Imagine that the string assignation is different for whatever reason in TheLib and MyLib, then the crash is not a surprise. Perhaps MyLib is using a COW-enabled string, while TheLib uses a simpler string implementation.

Another possible source of problems would be different allocators. The malloc of TheLib is not the malloc of MyLib, and as such, trying to reallocate the string's buffer to accomodate the copy would lead to a crash, too.

Answer 4

You post does not contain enough information to determine the problem. I suspect that the Variant class is not handling references properly. The problem is probably only accidental to the optimazation level: one happens to fail silently while the other fails loudly.

Answer 5

Bugs caused by optimisation settings are rare. I'd bet somewhere in your program you are relying on undefined or unreliable behavior, which should crash all the time, but by chance does not crash with particular optimisation setting. I'd say this is something else you're doing wrong, not your optimisation flags.