Bug accessing a global variable with 3d_armor
Closed this issue · 7 comments
Hi, terumet crashes with the following error:
Sep 11 09:14:35 aurelium-dev minetestserver[14142]: 2019-09-11 09:14:35: WARNING[Main]: Undeclared global variable "armor" accessed at /home/someguy/.minetest/mods/terumet/interop/3d_armor.lua:131
Sep 11 09:14:35 aurelium-dev minetestserver[14142]: 2019-09-11 09:14:35: ACTION[Main]: Server: Shutting down
Sep 11 09:14:35 aurelium-dev minetestserver[14142]: 2019-09-11 09:14:35: ERROR[Main]: ModError: Failed to load and run script from /home/someguy/.minetest/mods/terumet/init.lua:
Sep 11 09:14:35 aurelium-dev minetestserver[14142]: 2019-09-11 09:14:35: ERROR[Main]: /home/someguy/.minetest/mods/terumet/interop/3d_armor.lua:131: attempt to index global 'armor' (a nil value)
Sep 11 09:14:35 aurelium-dev minetestserver[14142]: 2019-09-11 09:14:35: ERROR[Main]: stack traceback:
Sep 11 09:14:35 aurelium-dev minetestserver[14142]: 2019-09-11 09:14:35: ERROR[Main]: /home/someguy/.minetest/mods/terumet/interop/3d_armor.lua:131: in main chunk
Sep 11 09:14:35 aurelium-dev minetestserver[14142]: 2019-09-11 09:14:35: ERROR[Main]: [C]: in function 'dofile'
Sep 11 09:14:35 aurelium-dev minetestserver[14142]: 2019-09-11 09:14:35: ERROR[Main]: /home/someguy/.minetest/mods/terumet/global.lua:106: in function 'do_lua_file'
Sep 11 09:14:35 aurelium-dev minetestserver[14142]: 2019-09-11 09:14:35: ERROR[Main]: /home/someguy/.minetest/mods/terumet/init.lua:260: in main chunk
I'm using the latest of both 3d_armor and terumet.
My guess is that you have 3d_armor installed, but not enabled. However, this is still a bug w/ terumet; It shouldn't be hard to fix.
I'll double check that a little later, I just updated 3d_armor to the latest version before I got this error. I'll make sure its installed and running correctly by itself then ill re-enable terumet.
@za267 I've just verified that you should never see this error - whether you have 3d_armor enabled or not, or even if it's not loading for some weird reason. get_modpath() should only ever return a value if the mod is or will be loaded; since terumet optionally depends on 3d_armor, 3d_armor must load first, and so the armor global should either exist, or get_modpath() should return nil and terumet should never try to access it.
Note that the documentation for get_modpath states that it's not reliable, but from reading the source code for the game, it certainly seems like it is between 5.0.1 and HEAD:master. I haven't checked if that caveat was once true in some older version. I've certainly been scolded for using get_modpath instead of global_exists in the past, by more knowledgeable devs.
So something weird is going on, but none of the weird things i can think of seem plausible:
- You're running an older, pre-5.0.1 copy of the minetest engine than you think (just like you were running an older copy of MTG than you thought).
- Some other mod is erasing the armor global for unknown reasons
- You're using a weird, non-standard version of 3d_armor (i.e. not HEAD:master on https://github.com/stujones11/minetest-3d_armor)
Knowing whether 3d_armor is actually enabled will be useful, as well as any subset of the following:
- The full debug.txt log for a single failed server boot (default log level - action - is fine, info level might be more useful)
- The contents of your world.mt file
- The contents of your minetest.conf file, stripped of any sensitive information like keys/passwords
- A full list of all the mods you have, and their versions/sources. Something like the mods meta-repo we have on BlS is super useful for publishing this: https://github.com/BlockySurvival/bls_mods
@fluxionary Your probably correct. I'll have to wipe out my entire build it seems, I've obviously messed up something with the branches I'm using.
Thanks so much for looking into this.
So, I did a full clean build this morning and tried it all again. I'm definitely on the correct branches now:
[someguy@aurelium-dev 3d_armor]$ git status
On branch master
Your branch is up to date with 'origin/master'.
====
[someguy@aurelium-dev terumet]$ git status
On branch master
Your branch is up to date with 'origin/master'.
I've added the files you requested and the debug includes an info level log of a single server start failure.
P.S. I saw parts of your conversation on #minetest, sorry for giving you so much trouble. Thanks again for the assistance.
I tried grepping for get_modpath with 'armor' to see how its being used, and I couldn't find anything in the terumet mod:
[someguy@aurelium-dev mods]$ grep -Rn 'armor' ./* | grep get_modpath
./ethereal/lucky_block.lua:72:if minetest.get_modpath("3d_armor") then
./homedecor/wardrobe.lua:15:local armor_mod_path = minetest.get_modpath("3d_armor")
./rainbow_ore/init.lua:4:if minetest.get_modpath("3d_armor") then
./rainbow_ore/init.lua:5:dofile(minetest.get_modpath("rainbow_ore").."/rainbow_armor.lua")
./stamina/init.lua:119:--local armor_mod = minetest.get_modpath("3d_armor")
but I assume from the minimal searching I've done, that 'armor' is supposed to be global whether or not 3d_armor is installed?
... still, it doesn't make sense considering the 3d_armor mod seems to be fully active.
Could it be a timing issue?
[someguy@aurelium-dev terumet]$ cat mod.conf
name=terumet
description=Terumetal v3.0 - Make life easier with alloys and heat machinery!
depends=default,bucket,screwdriver,farming,dye,basic_materials
optional_depends=unified_inventory,tubelib,walls,stairs,doors,tnt,mesecons,dungeon_loot,bushes,dryplants,vines,mobs_animal,main,extra
[someguy@aurelium-dev terumet]$ grep 3d_armor mod.conf
The terumet mod.conf doesn't mention 3d_armor as a dependency, soft or otherwise. I think this means terumet could potentially load before 3d_armor is registered? I may be totally off track here.
@fluxionary YAY! That fixed it!
optional_depends=3d_armor,unified_inventory,tubelib,walls,stairs,doors,tnt,mesecons,dungeon_loot,bushes,dryplants,vines,mobs_animal,main,extra