Search code examples
c++windowsassertionsrapidjsonc++17

Fully qualified source filepath showing in release candidate Assertion failure


I have a problem currently with a shipped version of our software. Under certain conditions an assertion is thrown which looks like the following...

enter image description here

This error message is embarrassing enough, but the sugar topping is that fact that some how there is a fully qualified reference of the source file that raises the exception... including my name! Obviously this was the location of that source during development, but this is a release candidate (for deployment) so I was under the assumption that no debug/symbols would be built into the binaries?

I tried looking through the various properties of the projects, but cannot deduce any option that may cause 'persisting' of fully qualified source filepaths in release builds. Is this a by product of an assertion being triggered in a release build, or have I missed something here. If this is standard behavior, how do others mitigate this issue for assertions (i.e ensure that a fully qualified path does not include any 'un-professional' strings if presented to the user).

P.S The assertion in this case is failed by rapidjson, which is a perfectly valid issue being raised here.


Solution

  • It appears that the symbol NDEBUG is not defined, otherwise assertions wouldn't be raised at all.

    You can define them explicitly in code as #define NDEBUG before any includes, or you could do it on the command line.

    VS would be Project Properties > C/C++ > Command Line, and you'd type \D "NDEBUG" for your release config (but not debug configuration).

    gcc you'd do -d NDEBUG

    clang you'd do -D NDEBUG