Command line arguments to the linker

Code:

---

/** Add a feature to a (mutable) LV2 feature array. */
static inline void
suil_add_feature(LV2_Feature*** features,
                unsigned*      n,
                const char*    uri,
                void*          data)
{
        for (unsigned i = 0; i < *n && (*features)[i]; ++i) {
                if (!strcmp((*features)[i]->URI, uri)) {
                        (*features)[i]->data = data;
                        return;
                }
        }

        *features = (LV2_Feature**)realloc(*features,
                                          sizeof(LV2_Feature*) * (*n + 1));

        // Initialize the new feature here (and increment the array size)
}

---

suil_add_feature is used to add features to an existing array of pointers to type LV2_Feature. Initially, the array gets searched to see if the feature already exists. If it doesn't, the existing array gets increased by one element which then gets initialized to the new LV2_Feature value. Resizing is done using realloc()

I'm having a problem when I build a Debug version. The first 5 times I call suil_add_feature() realloc() ends up calling _realloc_dbg() (in dbgheap.c) and everything works fine. But on the sixth call, realloc() calls _realloc_base() (in realloc.c) which brings everything crashing down. I assume that _realloc_base() is intended for the normal (non-debug heap). So this particular app is somehow linking to both the debug and non-debug runtime modules. :(

If I was building using the VS IDE I could probably figure this out - but although my compiler is MSVC, my build environment is waf, which I'm a bit unfamiliar with. I'm guessing I need to add some lines to my waf script to let it know that it shuld ignore the non-debug runtime libraries when building a Debug version.

Can I achieve this by adding /NODEFAULTLIB to the linker options or is it more complicated than that?

Is this static inline in a header, pulled in by multiple source files?

Is it pulled into multiple modules (DLL/EXE) that you're debugging together?

If you are just in a single module, then one of the source files may of been compiled without "_DEBUG".

If multiple modules are involved, and these modules pass pointers around that could be realloc'd - then all the modules should be compiled with the dynamic, debug CRT.

gg

Quote:

---

Originally Posted by Codeplug

Is this static inline in a header, pulled in by multiple source files?

Is it pulled into multiple modules (DLL/EXE) that you're debugging together?

If you are just in a single module, then one of the source files may of been compiled without "_DEBUG".

---

Yes, I think that's it. I've noticed that one of the manifest files for this project contains entries for both the Debug and non-debug runtimes although I still need to figure out why.

I think I might be wrong about realloc_base() being the non-debug equivalent of realloc_dbg(). A quick search of the relevant libraries revealed that both functions are found only in the debug versions of the 'C' runtime libraries. However - realloc_base() is found only in libcmtD.lib whereas realloc_dbg() appears in libcmtD.lib and also in msvcrtD.dll

So might this be a problem where one module is linking to the multithreaded static lib whereas another module is linked to the multithreaded DLL? Do they use different heap managers I wonder?

Trying to realloc or free a pointer from a heap that didn't produce that pointer is definitely bad. When multiple modules (EXE, DLL's) need to share a heap, you have to make sure that everyone links against the same dynamic CRT.

gg

Thinking about it overnight I'm pretty sure that this function shouldn't be inlined. In my experience, functions that either malloc or free memory on behalf of other module(s) need to be handled with great care - so that the same heap manager gets used no matter where they're called from. Usually the best way of achieving that is to put them in a DLL. Inlining is definitely asking for trouble I think. I'll contact the developer and explain the problem to him. It was originally a Linux library so maybe this kind of issue doesn't affect Linux? A Linux programmer might not be fully aware of it.

These issues exist on Linux, but usually all DSO's and executable images use a single "CRT" per process. So it may be easier to get away with malloc in one module, then free in another. You can get away with it on Windows too, as long as everyone uses the same CRT.

gg