The assertion is an important discovery - it means that a release mode binary will silently err there, with who knows what results - could be anything from nothing through a wrong written file to crashing completely. Whenever you get such an assertion, you should press Retry to drop into the debugger, and investigate the assert. Usually there is a comment next to it describing why the assert is there. Posting the assert together with the stacktrace (the Call stack window lets you copy its contents) could be useful, too, if you have just no idea on how to fix that. Usually the callstack is more important that the actual assert line, since the assert line is in some common code part, while the real cause is higher up the function call chain.
As for the poor performance, I have decided to disable the leak finder in the canon source. We haven't had any memory leaks for over a year now and when we do, the linux guys can find them with valgrind. VS2013 makes the leak finder really slow, next to unusable.
The SetSwimState failures are an issue of their own, I want the person who added the log to fix them!
As for the poor performance, I have decided to disable the leak finder in the canon source. We haven't had any memory leaks for over a year now and when we do, the linux guys can find them with valgrind. VS2013 makes the leak finder really slow, next to unusable.
The SetSwimState failures are an issue of their own, I want the person who added the log to fix them!