Viewing Issue Advanced Details
[ Jump to Notes ]
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
08242 Plugins Minor Always Mar 4, 2022, 15:35 Apr 1, 2022, 05:14
Tester Bletch View Status Public Platform MAME (Self-compiled)
Assigned To cuavas Resolution Fixed OS Windows 10/11 (64-bit)
Status [?] Resolved Driver
Version 0.241 Fixed in Version 0.242 Build 64-bit
Fixed in Git Commit dd1e5b1 Github Pull Request # #9419
Summary 08242: LUA error on Clang builds
Description For me, the following LUA code seems to fail on self-made Clang/Visual Studio builds:

    local file = emu.file(manager.machine.options.entries.cheatpath:value(), 1);
    file:open("cheat.blah");
    local blah = file:read(file:size());
    manager.machine:popmessage("blah: " .. tostring(blah));

The error seems to be:

[LUA ERROR] in execute_function: stack index 2, expected userdata, received number: value is not a valid userdata (bad argument into 'void) [T = sol::buffer *](void) [T = emu_file &], void) [T = sol::buffer *])')

The problem seems to be that file:read() fails, because it fails to convert the return value from file:size() to a number.

At first, I assumed this was a Sol 3 regression, but I later discovered that this does not seem to happen in any normal MinGW builds. I strongly suspect that this may be some sort of a compiler bug (perhaps with Clang or my older version of Clang), but I'd like to report it to see if anybody sees this problem elsewhere.
Steps To Reproduce 1. Paste the above snippet into `dummy.startplugin()` in plugins/dummy/init.lua
2. Ensure that a text file called "cheat.blah" is in your cheat path
3. 'mame anydriver -plugin dummy'
Additional Information
Github Commit
Flags
Regression Version
Affected Sets / Systems
Attached Files
  
Relationships
There are no relationship linked to this issue.
Notes
5
User avatar
No.19895
cuavas
Administrator
Mar 14, 2022, 04:46
 Well, the sol::buffer class is declared in src/frontend/mame/luaengine.ipp and the relevant sol_lua_get and sol_lua_push overloads are declared almost immediately afterwards. If the sol::buffer isn’t forward declared anywhere else, I don’t see why it shouldn’t work with any competent compiler. If you can make a minimal test case, maybe it can be reported to the clang people?
User avatar
No.19911
cuavas
Administrator
Mar 15, 2022, 05:16
 Actually, have you inadvertently turned on sol’s type checking in your clang builds? There’s no implementation of sol_lua_check or sol_lua_check_get for the sol::buffer class, so if type checking is on (or if you try to overload a Lua function that can accept a sol::buffer *), it will never think the arguments are suitable.
User avatar
No.19912
cuavas
Administrator
Mar 15, 2022, 13:58
 I bet that’s actually the case. Consider this:

#if defined(SOL_IN_DEBUG_DETECTED)
        #if SOL_IN_DEBUG_DETECTED != 0
                #define SOL_DEBUG_BUILD_I_ SOL_ON
        #else
                #define SOL_DEBUG_BUILD_I_ SOL_OFF
        #endif
#elif !defined(NDEBUG)
        #if SOL_IS_ON(SOL_COMPILER_VCXX_I_) && defined(_DEBUG)
                #define SOL_DEBUG_BUILD_I_ SOL_ON
        #elif (SOL_IS_ON(SOL_COMPILER_CLANG_I_) || SOL_IS_ON(SOL_COMPILER_GCC_I_)) && !defined(__OPTIMIZE__)
                #define SOL_DEBUG_BUILD_I_ SOL_ON
        #else
                #define SOL_DEBUG_BUILD_I_ SOL_OFF
        #endif
#else
        #define SOL_DEBUG_BUILD_I_ SOL_DEFAULT_OFF
#endif // We are in a debug mode of some sort

For MSVC-like compilers (which includes clang-cl) it automatically turns on all the expensive checks if _DEBUG is defined. For GCC or regular clang it automatically turns them on if optimisation is disabled.
User avatar
No.19913
cuavas
Administrator
Mar 15, 2022, 15:03
 Yep, that’s what’s happening – enabling all checks with GCC gives the same result.
User avatar
No.19914
cuavas
Administrator
Mar 15, 2022, 18:11
 sol::buffer seems misguided anyway, see https://github.com/mamedev/mame/pull/9419