nil check on get_luaentity() #3601
Labels
No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#3601
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
According to flux and wsor, get_luaentity() can return nil. This
is neither documented in https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L7154 nor do a lot of mods check for nil at this place.
Followup of #3597
it returns
nil
generally when eitheri'm not certain under which conditions
minetest.get_objects_inside_radius
would return stale references - looking at the code, it should be filtering them out.after a cursory review of the code, most of the places where
get_luaentity()
is used seem to be immediately after creating an object (minetest.add_entity()
) - which can fail if the object failed to be created, which is actually a rare occurrence.Happened again in a different piece of code: #3606
The servers it happened on were 5.7.0-dev. The live server which is 5.6.1 runs this piece of code flawlessly. Is it possible this is a 5.7.0+ problem?
The code at the specific location flux mentioned didn't change for 2 years, but maybe something else somewhere else did, that may have affected it?
Also I was told the maintainer of Mineclone experienced a similar problem here: https://git.minetest.land/MineClone2/MineClone2/pulls/3324/files
seems quite possible. which commit of 5.7.0-dev is the server?
Test Server says it's on b8aaad4f1, but git says it can't find this commit?
Maybe it was reverted?
However since the Mineclone maintainer also found a similar issue, I'd guess the problem is in more than one commit.
b8aaad4f1e
the immediate common denominator seems to be use of
get_objects_inside_radius
andget_objects_in_area
. assuming that anything which doesn't check whether the objects returned by those is a valid object, i've found the following issues:i'll rebuild my local server and see if i can't shake anything out
Not saying thats the culprit, just linked to the commit which is probably the one Alias git couldn´t find
i added a fix to moremesecons in a PR for something else: https://github.com/minetest-mods/MoreMesecons/pull/32
i guess we never put that logging code in the actual yl codebase
Should we?
this issue hasn't actually occurred in quite a while, has it? maybe if it resurfaces.
the MoreMesecons PR was accepted
well, i guess i summoned the bug by mentioning it: #5155
i added a modified version of that code to yl_commons:
a82eabdfb6
this version actually removes the "bad" objects from the return value so that other unsafe code won't crash, but note that it makes two of our most expensive functions even more expensive (see #3723). i should aim to patch all the other bad uses and then disable the "bugfix", but that's going to be a pain.
alias writes in #5253:
We have a couple of those in the log:
this is Amanda.
i added some code to add a stack trace to see if there's any pattern
b27043c302
2023-12-14 23:47:58: ERROR[Server]: LuaEntity name "water_life:crocodile" not defined
2023-12-14 23:48:00: ERROR[Server]: INVALID OBJECT?! {
2023-12-14 23:48:00: ERROR[Server]: INVALID OBJECT?! {
2023-12-14 23:48:01: ERROR[Server]: INVALID OBJECT?! {
There occurred 90 incidents lately, unfortunately the debug code was not yet ingame.
i'm pretty sure that was me trying to spawn one in to test something, not realizing that they name is "water_life:croc"
per #6575, the cause if this is probably almost always unknown objects.
i'm not sure why Amanda was implicated though, unless we started up the server w/out NPCs once, or in that intermediate era where they weren't aliased properly?
So the 100% repro is "unknown object" ? I'm fairly certain there was a brief time on main where we switched from one type of NPC to another, but they should never have been on for more than a minute or so, just in case I started the server by mistake. If NPCs were unknown objects, they're fairly easy to spot
yes, not sure about the rest of it though. there might be another cause.