WE Crashes Minetest when Loading (dot)we File

[LazyJ]

WorldEdit GitHub commit, 2014_10_24, fb49cc4bcc MIneteset engine, GitHub commit, 2014_12_09, dcc48976ce

I tried three times to transfer a small build (286 nodes) from one singleplayer world to another using //save and //load. I saved the build (//save shack), then copied the "shack.we" file to the schems folder of another singleplayer world, and then tried to place the build in that world using "//load shack". At this point, Minetest crashed each time.

Here are error messages from the terminal output:

05:17:17: ERROR[main]: ServerError: ...ty_mods/WorldEdit_2014_10_24/worldedit/serialization.lua:172: bad argument #2 to 'insert' (number expected, got nil)
05:17:17: ERROR[main]: stack traceback:
05:17:17: ERROR[main]:  [C]: in function 'insert'
05:17:17: ERROR[main]:  ...ty_mods/WorldEdit_2014_10_24/worldedit/serialization.lua:172: in function 'load_schematic'
05:17:17: ERROR[main]:  ...ty_mods/WorldEdit_2014_10_24/worldedit/serialization.lua:219: in function 'deserialize'
05:17:17: ERROR[main]:  ...ty_mods/WorldEdit_2014_10_24/worldedit_commands/init.lua:978: in function 'func'
05:17:17: ERROR[main]:  ...f/01_minetest/lazyj/bin/../builtin/game/chatcommands.lua:40: in function <...f/01_minetest/lazyj/bin/../builtin/game/chatcommands.lua:29>
05:17:17: ERROR[main]:  ...stuff/01_minetest/lazyj/bin/../builtin/game/register.lua:348: in function <...stuff/01_minetest/lazyj/bin/../builtin/game/register.lua:336>

[Uberi]

Seems like something got corrupted somewhere - can you upload the schematic for testing?

As a temporary workaround until this is fixed, try a build without LuaJIT.

[LazyJ]

Minetest engine, GitHub commit, 2014_12_10, fb80a7c111

Requested schematic, same build, 2 files (1 LuaJIT, 1 without), default nodes: With LuaJIT - we_luajit.we https://dl.dropboxusercontent.com/u/30991334/we_luajit.we

Without LuaJIT - we_no_luajit.we https://dl.dropboxusercontent.com/u/30991334/we_no_luajit.we

I compiled Minetest without LuaJIT (-DDISABLE_LUAJIT=1) and another instance with LuaJIT.

In the LuaJIT instance I //saved we_luajit and then tried //loading it in another world - Minetest crashed with the same errors.

Then I copied both worlds into the non-LuaJIT instance, //saved we_no_luajit, and successfully //loaded it into the other world.

While still in the non-LuaJIT, I then tried //loading the we_luajit file and it worked.

Following that, I copyied we_no_luajit.we into a world in the LuaJIT compiled instance of Minetest and Minetest crashed when I tried to //load the schematic with the same error.

So it would seem that the //save process works in both non-LuaJIT and LuaJIT compiled instances of Minetest but the //load process is fubared.

While using WorldEdit in the non-LuaJIT instance, these errors came-up in the terminal:

05:33:41: WARNING: Undeclared global variable "jit" accessed at ...ods/WorldEdit_2014_10_24/worldedit/serialization.lua:157
05:33:41: ERROR[ServerThread]: Assignment to undeclared global "z" inside a function at ...ods/WorldEdit_2014_10_24/worldedit/serialization.lua:202.
05:33:41: ERROR[ServerThread]: Assignment to undeclared global "y" inside a function at ...ods/WorldEdit_2014_10_24/worldedit/serialization.lua:202.
05:33:41: ERROR[ServerThread]: Assignment to undeclared global "x" inside a function at ...ods/WorldEdit_2014_10_24/worldedit/serialization.lua:202.

I hope this helps.

[VanessaE]

I can confirm this bug also. Another example schematic that crashes Minetest (with the same error/backtrace as LazyJ initially reported; I use LuaJIT also):

http://digitalaudioconcepts.com/vanessa/hobbies/minetest/oldspawn.we

In my case, I was simply trying to reload the schematic into another area in the same world from which it was just saved a minute or so prior (I was moving the "spawn building" in one of my worlds).

[Uberi]

I think this should be fixed in 04fdf92aca66641de87a6e7d00de2bdd796858d1 - give it a try! Your test cases were very useful - for some reason minetest.deserialize now returns two values rather than one, which messed up our entry insertion.