8000 require returns chunk name/string instead of require'd contents · Issue #567 · mlua-rs/mlua · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

require returns chunk name/string instead of require'd contents #567

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed 8000
cheesycod opened this issue Apr 27, 2025 · 5 comments
Closed

require returns chunk name/string instead of require'd contents #567

cheesycod opened this issue Apr 27, 2025 · 5 comments

Comments

@cheesycod
Copy link
cheesycod commented Apr 27, 2025

Not sure if its my implementation of require trait thats at fault here but require seems to be returning the chunk name string instead of the loaded module in some cases:

e.g:

abc.luau of:

b = require "./c"
return b

c.luau of

return {a = function() end}

init.luau of

a = require"./c"
print(a)

For some reason, this prints the string init.luau (chunk name) for me sometimes instead of the require'd table which is weird as my load function does in fact return the LuaValue correctly.

As another oddity, the require works when each require is executed as individual calls (e.g. in a REPL), but not when the whole file is executed at the same time (there, the chunkname is returned instead of the require'd data)

For more context (if it helps), im loading everything using lua.create_thread followed by thread.resume and in my require, im using normal/standard lua.load. The lua.load call works as expected and prints out the table when I added a print statement but the returned value that the caller recieved (in lua) was the chunk name string of the caller itself

@cheesycod
Copy link
Author
cheesycod commented Apr 27, 2025

@khvzak so i debugged the problem further, not fully sure whats going on but it seems to be related to running require from within a lua thread (???) which then for some reason doesn't seem to return the right results for some reason (im not proficient with lua stack so thats as far as i can go). I can send code for debugging tho.

You can see the buggy require trait here: https://github.com/Anti-Raid/khronos/blob/requirev2-n/crates/runtime/src/utils/require_v2.rs

@khvzak
Copy link
Member
khvzak commented Apr 27, 2025

Do you have a short example / steps to reproduce?

@cheesycod
Copy link
Author
cheesycod commented Apr 27, 2025

Do you have a short example / steps to reproduce?

@khvzak sure:

https://github.com/cheesycod/mlua-require-bug

Compile with cargo build and run with target/debug/test-mlua

The expected output: a table
What you get instead: Ok(String("@./examples/repl.rs"))

@cheesycod
Copy link
Author
cheesycod commented Apr 27, 2025

@khvzak

Have debugged it a bit more, I dont think mlua is pushing the value to the right stack (if the push is working at all). If i modify mlua to do a ffi::pushnumber(state, 1.0) after stack push, the 1.0 is printed out from require.

Also, doesn't Lua::init_from_ptr do a mainthread() for state? If so, wouldnt pushing to stack here push the value to the main state and not the state passed from luau require (which would work for lua_load but fail once threads get introduced). That also explains why it works create_thread + resume, outside of threads, the state passed by luau require and the main thread would match so the push would work (this is just my assumption and there could be other causes)

@khvzak khvzak closed this as completed in edd508e Apr 27, 2025
@khvzak
Copy link
Member
khvzak commented Apr 27, 2025

Thank you for the report. It's fixed now.

khvzak added a commit that referenced this issue May 5, 2025
Remove manual usage of `StateGuard` in other places.
Closes #567
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
0