With ClanLib 2.0.4 I noticed that printing a ClanLib-thrown exception caught as a std::exception produced only nonsense bytes which varied every run. Running under valgrind confirmed my suspicions: an invalid pointer was coming up.

I found the problem soon enough: CL_Exception::what() constructs a temporary CL_String8 using CL_StringHelp::text_to_local8 and then returns its c_str(). Unfortunately, that temporary is released when what() returns.

When UNICODE is not #defined, this problem doesn't show up, since text_to_local8 simply returns the given string, which is stored safely inside the CL_Exception. With UNICODE #defined, however, text_to_local8 does create a new string which is then immediately freed by its destructor on returning from what(), and we have a classic "use after free" situation.

I don't know enough about the ClanLib internals to know how this should be fixed (I'm just starting out with it), so I'm afraid I can't provide a patch. It's not a completely horrible issue as it's relatively easy to work around: catch CL_Exception separately from std::exception and use e.message there instead of e.what().