Problem
src/LuaEngine/HttpManager.h includes the vendored libs/httplib.h without CPPHTTPLIB_OPENSSL_SUPPORT, while HttpManager.cpp defines the macro before including it. Every other TU that pulls HttpManager.h (e.g. via GlobalMethods.h) therefore instantiates the non-SSL variant of cpp-httplib's inline functions, while HttpManager.cpp instantiates the SSL variant.
The macro changes httplib::ClientImpl's member layout and inline function bodies, so the binary ends up with two divergent definitions under identical mangled symbols - an ODR violation. The linker keeps one copy per symbol and freely mixes the two layouts. Whether the https path works is linker luck, not correctness.
Evidence this is real, not theoretical
This exact mechanism crashed the Merkerhood worldserver: mod-discordBot vendors the same httplib 0.13.1 with the SSL macro, the linker mixed its instantiation with mod-ale's non-SSL one, and the first real https POST SIGSEGV'd on a member read at the wrong offset (Merkerhood/mod-discordBot#5, core backtrace shows one call chain interleaving both copies with scrambled arguments; fixed on the discordBot side by namespace isolation in Merkerhood/mod-discordBot#6).
mod-discordBot is now immune, but mod-ale's own instantiations still disagree with each other: Lua HttpRequest against an https URL can hit the same class of corruption depending on which symbol copies the linker keeps.
Suggested fix
Make every include of libs/httplib.h see the same macro configuration. Simplest: move #define CPPHTTPLIB_OPENSSL_SUPPORT into HttpManager.h directly above its #include "libs/httplib.h" (and drop the now-redundant define in HttpManager.cpp, keeping include order so the .h comes first). Alternatively hoist the define into the build flags for the module.
Verification idea
After the fix, nm -C over the mod-ale objects should show a single consistent set of httplib:: symbols, and a Lua script doing an https HttpRequest should round-trip cleanly.
Problem
src/LuaEngine/HttpManager.hincludes the vendoredlibs/httplib.hwithoutCPPHTTPLIB_OPENSSL_SUPPORT, whileHttpManager.cppdefines the macro before including it. Every other TU that pullsHttpManager.h(e.g. viaGlobalMethods.h) therefore instantiates the non-SSL variant of cpp-httplib's inline functions, whileHttpManager.cppinstantiates the SSL variant.The macro changes
httplib::ClientImpl's member layout and inline function bodies, so the binary ends up with two divergent definitions under identical mangled symbols - an ODR violation. The linker keeps one copy per symbol and freely mixes the two layouts. Whether the https path works is linker luck, not correctness.Evidence this is real, not theoretical
This exact mechanism crashed the Merkerhood worldserver: mod-discordBot vendors the same httplib 0.13.1 with the SSL macro, the linker mixed its instantiation with mod-ale's non-SSL one, and the first real https POST SIGSEGV'd on a member read at the wrong offset (Merkerhood/mod-discordBot#5, core backtrace shows one call chain interleaving both copies with scrambled arguments; fixed on the discordBot side by namespace isolation in Merkerhood/mod-discordBot#6).
mod-discordBot is now immune, but mod-ale's own instantiations still disagree with each other: Lua
HttpRequestagainst an https URL can hit the same class of corruption depending on which symbol copies the linker keeps.Suggested fix
Make every include of
libs/httplib.hsee the same macro configuration. Simplest: move#define CPPHTTPLIB_OPENSSL_SUPPORTintoHttpManager.hdirectly above its#include "libs/httplib.h"(and drop the now-redundant define inHttpManager.cpp, keeping include order so the .h comes first). Alternatively hoist the define into the build flags for the module.Verification idea
After the fix,
nm -Cover the mod-ale objects should show a single consistent set ofhttplib::symbols, and a Lua script doing an httpsHttpRequestshould round-trip cleanly.