CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7
  1. #1
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    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?
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  2. #2
    Join Date
    Nov 2003
    Posts
    1,902

    Re: Command line arguments to the linker

    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

  3. #3
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: Command line arguments to the linker

    Quote Originally Posted by Codeplug View Post
    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.
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  4. #4
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: Command line arguments to the linker

    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?
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  5. #5
    Join Date
    Nov 2003
    Posts
    1,902

    Re: Command line arguments to the linker

    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

  6. #6
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: Command line arguments to the linker

    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.
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  7. #7
    Join Date
    Nov 2003
    Posts
    1,902

    Re: Command line arguments to the linker

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured