Closed vallentin closed 5 months ago
I cloned the repo and ran cargo test
and multiple_userdata()
in userdata.rs
segfaulted.
Removing all assert
s at the end of the test, and there's no segfault, but simply executing one / the first, triggers a segfault. So the segfault is first triggered when executing Lua code.
This seems to be further proved, by the segfault being triggered in call_with_args()
by ffi::lua_pcall()
.
_Still in the multiple_userdata()
(userdata.rs
) test._
If we remove the custom Integer
type, then the following passes:
lua.set("add", hlua::function0(|| 123));
assert_eq!(
lua.execute::<u32>("return add()").unwrap(),
123
);
While if we wrap it in Integer
, then it segfaults:
lua.set("add", hlua::function0(|| Integer(123)));
assert_eq!(
lua.execute::<Integer>("return add()").unwrap().0,
123
);
Clearly, it has something to do with resolving userdata back into Rust types.
I found the culprit. It seems that the pointer returned by lua_newuserdata
might be unaligned. Which triggers the segfault when it is dereferenced:
misaligned pointer dereference: address must be a multiple of 0x10 but is 0x22c615c7ef8
I will write a PR to resolve the issue.
I'm unsure if this is platform specific, since I was confused why it hadn't been reported yet.
I attempted to create a namespace with methods for a custom type. However, calling any method immediately segfaulted. I thought I had a typo somewhere, but when I ran the sound-api.rs example (on Windows 10), using
hlua = "0.4.2"
it also segfaulted:I tested the Lua code line by line, and the segfault is caused by
s:play()
, or more precisely by calling any method, e.g.s:play()
,s:is_playing()
,s:stop()
.I also noted that if only
Sound.new()
is executed, then it successfully runs theSound
destructor, i.e.hlua
callingdrop
internally does not result in a segfault.I went digging a bit, and
hlua = "=0.3.1"
does not segfault, while the next versionhlua = "=0.4.0"
does.Digging a bit further, and https://github.com/tomaka/hlua/commit/b38af4200466f278850171bdff7cc74658f0f92b is the commit introducing the segfault, while the previous commit https://github.com/tomaka/hlua/commit/634a4dee5a0d1d0418287b95dfa77a524b502862 does not cause any segfault.
i.e. first version causing segfault:
vs last good version not causing a segfault:
I didn't dig any further than that so far. I'll happily provide any other information needed.