clang 18 and 19 produce memory leak in `readOnlyError` implementation

[ped7g]

I use LuaBridge in Z80 assembler sjasmplus.

When I build it with clang-18 or clang-19 with asan (CFLAGS_EXTRA='-fsanitize=address' LDFLAGS='-ldl -fsanitize=address'), I get memory leak reported in LuaBridge detail/CFunctions.h:186:

=================================================================
==46284==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 62 byte(s) in 2 object(s) allocated from:
    #0 0x5df03d1f0821 in operator new(unsigned long) (/home/ped/.local/bin/sjasmplus+0x13e821) (BuildId: 8fab575ed2e96f315f0bb548acf76c4e182ab254)
    #1 0x7681d256870e in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::_M_mutate(unsigned long, unsigned long, char const*, unsigned long) /build/gcc-14-ig5ci0/gcc-14-14.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:332:30
    #2 0x7681d256a04f in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::_M_append(char const*, unsigned long) /build/gcc-14-ig5ci0/gcc-14-14.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:424:17
    #3 0x5df03d23307f in luabridge::detail::CFunc::readOnlyError(lua_State*) (/home/ped/.local/bin/sjasmplus+0x18107f) (BuildId: 8fab575ed2e96f315f0bb548acf76c4e182ab254)
    #4 0x5df03d2b9acd in precallC ldo.c

Direct leak of 31 byte(s) in 1 object(s) allocated from:
    #0 0x5df03d1f0821 in operator new(unsigned long) (/home/ped/.local/bin/sjasmplus+0x13e821) (BuildId: 8fab575ed2e96f315f0bb548acf76c4e182ab254)
    #1 0x7681d256870e in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::_M_mutate(unsigned long, unsigned long, char const*, unsigned long) /build/gcc-14-ig5ci0/gcc-14-14.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:332:30
    #2 0x7681d256a04f in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::_M_append(char const*, unsigned long) /build/gcc-14-ig5ci0/gcc-14-14.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:424:17
    #3 0x5df03d232f54 in luabridge::detail::CFunc::readOnlyError(lua_State*) (/home/ped/.local/bin/sjasmplus+0x180f54) (BuildId: 8fab575ed2e96f315f0bb548acf76c4e182ab254)
    #4 0x5df03d2b9acd in precallC ldo.c

SUMMARY: AddressSanitizer: 93 byte(s) leaked in 3 allocation(s).

JFYI the Lua error messages are triggered by test code trying to write into read-only variable:

28    0000                  LUA
29    0000 ~                    sj.warning_count = 3
lua_coverage.asm(30): error: [LUA] 'warning_count' is read-only
30    0000                  ENDLUA

The Lua part is sj.warning_count = 3, rest is assembler listing, the 'warning_count' is read-only part of error string is produced by LuaBridge.

I can't figure out why this C++ code would leak memory, this looks correct to me:

        std::string s;

        s = s + "'" + lua_tostring(L, lua_upvalueindex(1)) + "' is read-only";

        return luaL_error(L, s.c_str());

Am I just too thick, or is this compiler bug or is this leaking somehow for real and why/how? (I'm not formal C++ expert, so I may be also missing something obvious)

[ped7g]

Staring at this for few more minutes... isn't there some C vs C++ animosity and mem allocator difference used in std::string or constructor/destructor invocation happening? Or maybe just asan incorrectly tracking release of the allocated memory.

Too lazy to check the resulting machine code at this moment, looking for more opinions what this could be, but I would rather suspect std::string s destructor invocation missing for some wrong (compiler error) or valid (C vs C++) reason than asan tracking allocations wrongly (making up leak which doesn't exist).

[kunitoki]

This is because you compiled lua as C and luaL_error will longjmp and stack allocated c++ instances until that frame won't have their destructor called.

[ped7g]

sounds plausible, I can confirm I'm building it as C lib and including:

#include "lua.hpp"
#include "LuaBridge/LuaBridge.h"

Ok, I will try to compile it as C++, I wasn't aware it's possible to do that, thanks for tip. I will close the issue later with summary of my attempt? Or feel free to close anyway, as I guess it is resolved on LuaBridge side.

[ped7g]

After building Lua as C++ library there's no more memory leaking reported by asan.
So for me and sjasmplus project this issue is resolved.

JFYI the LuaBridge test does use Lua as C library, so I guess technically it would leak memory if it would test the read-only error message? Which I guess doesn't matter, as it doesn't really affect result of test.

And I don't see any mention of this peculiarity in the docs.

To LuaBridge maintainers: I'm leaving this open for you to decide if you want to take some action also on LuaBridge side, feel free to close the issue as you see fit.