External library seems to cause heap corruption when used in Cinder, but not outside of it...?

4

Hopefully you don’t me mind picking your brain again @lithium. As my good fortune would have it, I ran into the exact same issue again with a different library again (Dpp). The library uses call-back functionality to handle various behaviors which make it murky for me to see whether the allocation of STL objects actually crosses Application / DLL boundaries. See sample code below:

dpp::cluster bot( "discord_bot_token" );

    bot.on_ready([&bot](const dpp::ready_t& event) {
        bot.log(dpp::ll_info, "Logged in as " + bot.me.username);
    });

    bot.on_message_create([&bot](const dpp::message_create_t& event) {
        if (event.msg->content == "!ping") {
            bot.message_create(dpp::message(event.msg->channel_id, "Pong!"));
        }
    });

    bot.on_log([](const dpp::log_t& event) {
        std::cout << dpp::utility::loglevel( event.severity ) << ": " << event.message << "\n";
        if (event.severity > dpp::ll_trace) {
            std::cout << dpp::utility::loglevel(event.severity) << ": " << event.message << "\n";
        }
    });

    bot.start(false);

Unfortunately, regardless of what the library does or doesn’t do, it still triggered the same heap corruption error (__acrt_first_block == header). Not seeing an easy way to work-around the problem in this library (no .toCString() here), I decided to google the specific error, leading to this page:

https://docs.microsoft.com/en-us/answers/questions/240332/assert-when-using-mtd-dynamic-library.html

The explanation on that page further supports your previous advice. But that doesn’t provide a straight-forward solution for using dpp. Therefore, based on the explanation I thought to re-compile my application using ‘Multi-Threaded DLL’ (MD) as opposed to just ‘Multi-Threaded’ (MT). This results in the error going away.

So why this giant epilogue? Well - I’d still like your advice on these details if you’re willing to offer it. I’ve further read up a bit on using MD v. MT:

Cinder’s CMake by default builds with MT, but the general sentiment on the stackoverflow appears to be to favor MD if you plan to link with external DLLs. I’m admittedly a bit worried that the issue has now just become invisible rather than disappeared, although if one is forcing the executable and DLLs to use the same heap manager, it would seem that the problem ‘should’ actually be solved…?

Thoughts?

Cheers,
Gazoo