Unknown object appears in front of all signs

[sbrl]

Hello!

I've been experimenting with this mod, and it works great! However, I've come across a nasty bug in which the pink unknown object appears in front of all signs created with this mod.

Reproduction steps:

1. Place a sign / clock from this mod - optionally adding some text
2. Log out
3. Restart the server
4. Log in again
5. Note the unknown object in front of the signs
6. Note that the unknown object persists, even when you remove the sign

[pyrollo]

Hello,

Pink unknown object is very likely to be the entity used for dynamic display. This could occur if the entity is not defined anymore (change in the mod, disabling the mod).

I did the same thing and did not have this problem. I must have missed something.

• Did you use the last version of display_modpack ?
• Have you enabled / disabled any mod between the two logins ?
• Have you updated display_mod between the two logins ?
• Is the text (and clock needles) still displaying when unknown objects are present ?

If you can easily reproduce this bug, I'm interested in having more information about versions.

Thanks in advance for your replies.

[sbrl]

Thanks for the reply.

Hrm. I noticed that I hadn't gotten the latest updates to this mod - so I'm now using the latest master via git. Here's a screenshot of the issue:

Note that the pink unknown object thingys persist even when I break the associated sign behind each one, and then relog. They even persist past a reboot of the server!

I tried to do some more testing to track down the issue, but if I try to edit a poster now that I've updated display_modpack, I get this exception:

Runtime error from mod 'signs' in callback item_OnPlace(): ...inetest-server/worldmods/display_modpack/signs/nodes.lua:31: attempt to call field 'make_multiline_texture' (a nil value)
2018-07-09 11:40:22: ERROR[Main]: stack traceback:
2018-07-09 11:40:22: ERROR[Main]:   ...inetest-server/worldmods/display_modpack/signs/nodes.lua:31: in function 'on_rightclick'
2018-07-09 11:40:22: ERROR[Main]:   /usr/local/share/minetest/builtin/game/item.lua:423: in function </usr/local/share/minetest/builtin/game/item.lua:416>

Here's what I did:

1. I placed a poster
2. I tried to edit it by right clicking on it
3. I got an exception, and the server crashed
4. I logged back in, and the poster was just where I left it
5. I tried to edit it again, and it crashed again
6. I logged back in again, and now I see the pink 'unknown object' thing in front of it. Screenshot:

[pyrollo]

Oh ! Sorry for the poster crash, this was due to yesterday update. It is fixed now.

In the first screenshot I see you are using a sign that is not (or no more) in display_modpack. Just to make sure :

• What the item string of the sign you are using ?
• Are you also using kaeza's/VanessaE's signs_lib mod ?

[sbrl]

Cool, thanks!

What the item string of the sign you are using ?

It's signs:paper_poster.

Are you also using kaeza's/VanessaE's signs_lib mod ?

I think so. That mod is installed to worldmods/signs_lib, with the git remote url https://github.com/minetest-mods/signs_lib. Do they conflict?

This time, when testing, I did this:

1. Placed a poster
2. Edited the contents
3. Pressed Write and then Close

....but unlike last time, the unknown object pink thingy appeared as soon as I pressed Close:

[pyrollo]

There should not conflict any more but they did in the past. As they are using a similar trick with entities, this is a possibility. I'll test that and hope to reproduce that nasty bug.

[pyrollo]

Can you give the list of all active mods on your server ? That may due to another conflict, who knows.

[sbrl]

Thanks! Here's a list of mods I've got installed in my worldmods folder:

abriglass
abripanes
bakedclay
biome_lib
carpets
cement
darkage
datastorage
display_modpack
floating_anchor
flowerpot
frame
gates
hotbar
luacmd
mesecons
moretrees
pie
pipeworks
plants
plasticbox
quartz
rainbow_source
rgblightstone
signs_lib
simple_skins
tnt_extras
travelnet
ts_furniture
unifieddyes
unified_inventory
vines
we_env
whitelist
wield3d
wielded_light
worldedit
worldeditadditions
xconnected
xdecor

[sbrl]

2 of these are mods I've written myself - those are worldeditadditions and floating_anchor.

[pyrollo]

Someone else got the same issue recently as told on minetest forum :

My latest test round:

Removed all mods from /mods directory and write a default (clean - no mods) world.mt file. Fire up the server. I now have a default server with no mods installed.

Added Display Modpack 1.2 into mods directory and modified the world.mt file to enable all entries from Display Modpack 1.2.

Code: Select all

display_modpack-master

###
load_mod_steles = true
load_mod_signs_road = true
load_mod_signs_api = true
load_mod_font_api = true
load_mod_font_metro = true
load_mod_signs = true
load_mod_boards = true
load_mod_display_api = true
load_mod_ontime_clocks = true
###
##### display_modpack-master #####

I now have a default world setup with only Display Modpack 1.2 mod installed and enabled.

So, now I log in (client) and talk a look around. The previous "gold frameless clock" with the "unknown object" block can be seen on the left in Picture 03. I then craft a new "gold frameless clock" and mount it on the stone wall on the right. Initially, the clock looks great and works fine as you can see in Picture 03.

ts20181124_03.jpg Picture 03 (911.36 KiB) Not downloaded yet

When I log out, then log back in, that's when the "unknown object" shows up and stays there forever afterwards. See Picture 04.

ts20181124_04.jpg Picture 04 (1005.03 KiB) Not downloaded yet

So, then I remove the clocks by using a tool and the clock correctly destroys and moves to my inventory as it should, but the "unknown object" nodes remain. See Picture 05.

ts20181124_05.jpg Picture 05 (1005.67 KiB) Not downloaded yet

And finally, the only way to get rid of the "unknown object" nodes is to run /clearobjects. This will get rid of the remaining "unknown object" nodes.

In case it matters:

Server system: Raspberry Pi 2 Model B Rev. 1.1 running Raspbian Lite (Debian 9.6) Minetest Server Version 0.4.17-1 compiled from source Display Modpack Version 1.2

Clients Tested: Minetest Client Version 0.4.16 on Ubuntu Linux 18.04.1 LTS Minetest Client Version 0.4.17 on Windows 10

Other mods enabled: adv_spawning / craftguide-master / minetest-bookmarks_gui-1.0.0 / mobf / animalmaterials / creature-mob-engine / minetest-inventory_plus-master / animals / display_modpack-master / minetest-mods-mesecons-df4e880 / areas-master / minetest-3d_armor-version-0.4.12 / Minetest_WorldEdit_1.2

[sbrl]

Could it be a consistency issue or a race condition? Where the server shuts down or the chunk unloads at the exact moment this mod is in the middle of doing something to it?

[pyrollo]

Hi sbrl, do you still have this issue ? If yes, can you add the following code anywhere (for example in display_api/init.lua) :

minetest.register_chatcommand("pyr", {
    params = "",
    description = "Dump entities in a 10 nodes radius",
    func = function(name, param)
        local player = minetest.get_player_by_name(name)
        if not player then
            return false, "Player not found"
        end
        local count=0
        local output = '\n***** Entity dump start *****'
        for _, objref in pairs(minetest.get_objects_inside_radius(player:get_pos(), 10)) do 
            if not minetest.is_player(objref) then
                local entity = objref:get_luaentity() 
                output = output..'\n"'..entity.name..'" at '..minetest.pos_to_string(objref:get_pos())
                output = output..'\n'..dump(entity)
                count = count + 1
            end
        end
        minetest.log('action', output..'\n***** Entity dump stop *****\n')
        return true, count.." entities dumped in log"
    end,
})

Then :

• Go near the "unknown object"
• Issue "/pyr" chat command
• From debug.txt, copy paste result of this command (between "***** Entity..." lines)

This may help identifying the entities involved.

[sbrl]

Sure! Yeah, I'm still experiencing this issue I assume this command only outputs debug information, and doesn't delete anything from my world?

I've run the command 2 times at lightly different distances from a number of 'unknown entity' things (all of which have had the actual item behind it long-since removed). It's in somewhat of a built-up area, but I may be able to obtain more data from an alternate location if this proves problematic.

https://privatebin.net/?5f9a1971a48dbcbb#D63WZlKRqu+QPT8QvTnCSGXA6uj0PDhXPCKqKdlzK7c=

[pyrollo]

This command is safe, only debug info :)

Thanks a lot, things are getting clearer. This seems to be an issue with integer format in LUA. I guess it depends on the implementation because I don't get the same results.

To link the entity to the node, a hash of the node position is stored in the entity. When you come back to the sign/clock, hash is retrieved from the entity fields. It seems that in some implementation, only 32 bits (X and Y but not Z) are retrieved.

In your case, 32 higher significant bits are set to 1, which sets the Z part of the pos to 32767. In Riverty case (on the forum), the retrieved hash is 32 bits signed integer max value. On my machine and most server, all 48 bits of the hash are kept.

Just because I'm curious, on what machine/os are you running your server ?

The solution will be: stop using position hash and store x, y and z in the entity. I'll change that as soon as possible. This should solve the issue but you may still need to clear Unknown Objects with /clearobjects command.

[pyrollo]

An issue that could be similar: https://github.com/minetest-mods/pipeworks/pull/192

[12Me21]

Lua uses 64 bit floats (I'm pretty sure) for all numbers so there shouldn't be a problem with varying levels of precision (you should get ~53 bits of precision for integers)

[pyrollo]

Yes Lua is supposed to use 64 bits floats. But it seems that it could be changed at compilation time. It's unlikely that LUA on some systems is complied with anonther type.

What I suspect is a serialization or storage problem on some system that truncates some bits. Anyway obviously something is happening, I'm going to circumvent that by storing the position non hashed.

I would realy like to know what is the root cause of the problem but, not being able to reproduce it, it will be hard to study it.

[pyrollo]

Attempt to fix that issue is ready on branch entity_bug. Please download and test this version If result is satisfying, I'll merge to master branch.

[pyrollo]

Seems to be fixed according to Riverty:

I checked your test version on my server.

First, on first login to the game the one "Unknown Object" I kept for testing was gone! Good sign. I mounted two new clocks (Gold & White) = OK. Ran away then back check = OK. Log out, log back in check = OK. Reboot server, log in and check = OK. Mounted 2 new signs = OK. Server load check = OK. Server log check = OK.

[sbrl]

Cool, thanks @pyrollo! Those unknown objects do appear to have, erm, disappeared.

I'm using a Raspberry Pi 3 as my server. Here's some system information:

$ uname -a
Linux SERVER_NAME 4.14.82-v7+ #1165 SMP Wed Nov 21 16:42:28 GMT 2018 armv7l GNU/Linux
$ lscpu
Architecture:          armv7l
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
Model:                 4
Model name:            ARMv7 Processor rev 4 (v7l)
CPU max MHz:           1200.0000
CPU min MHz:           600.0000
BogoMIPS:              38.40
Flags:                 half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.6 (stretch)
Release:    9.6
Codename:   stretch

[pyrollo]

Thanks Sbrl ! Issue is solved at last... sorry that you had to wait so long.

Riverty is also on a Rapsberry under Linux.

I presume that the root cause is :

On Rapsberry Pi, minetest.serialize truncates big integers making it impossible to store a position hash into a serialized table.

[sbrl]

Ah, I see! As a modder myself (though I haven't gotten into persistence yet), that's really useful to know. Indeed, I suspect that's the issue. Armv7 is actually 32-bit (it's armv8+ that's 64bits) - it's probable that's at least a factor. The serialize() is probably backed by some C++ somewhere that's causing the issue.

[pyrollo]

Issue opened on minetest project : https://github.com/minetest/minetest/issues/7925 Yes it's important to know about. This was not obvious at all ! I want to do some more test on the fix and I'll merge it in the master branch soon.

[sbrl]

Cool, thanks!

[pyrollo]

Fixed in a3e0d36a68247cac40349d9089fe3c71546d75e8