Server bedrock crash during the game
Version: 1.16.201.2
OS: Linux
Server start: 2020-12-16 23:27:35 UTC
Dmp timestamp: 2020-12-17 14:40:32 UTC
Upload Date: 2020-12-17 14:40:32 UTC
Session ID: 7567d6a9-a582-425f-a105-64846da7001d
Commit hash:
Build id: development
CrashReporter Key: 76ce1a57-7cd8-3005-9f78-5a0a16ec0167
Crash
[INFO] at std::_shared_count<[__gnu_cxx::_Lock_policy]2>::shared_count[std::_weak_count<[__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::_shared_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2>::shared_ptr[std::_weak_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::shared_ptr<POIInstance>::shared_ptr[std::weak_ptr<POIInstance> const&, std::nothrow_t] (UnknownFile:?)
at std::weak_ptr<POIInstance>::lock[] const (UnknownFile:?)
at Village::getBedPOICount[] const (UnknownFile:?)
at Village::canRemove[] const (UnknownFile:?)
at VillageManager::_removeEligibleVillages[] (UnknownFile:?)
at VillageManager::tick[Tick const&] (UnknownFile:?)
at Dimension::tick[] (UnknownFile:?)
at Level::tick[] (UnknownFile:?)
at ServerLevel::tick[] (UnknownFile:?)
at GameSession::tick[] (UnknownFile:?)
at Minecraft::tickSimtime[int, int] (UnknownFile:?)
at Minecraft::update[] (UnknownFile:?)
at ServerInstance::_update[] (UnknownFile:?)
at clone (UnknownFile:?)
Environment
Ubuntu 20.04.1 LTS
Linux craft 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Linked Issues
is duplicated by5
Created Issue:
Server bedrock crash during the game
Version: 1.16.201.2
OS: Linux
Server start: 2020-12-16 23:27:35 UTC
Dmp timestamp: 2020-12-17 14:40:32 UTC
Upload Date: 2020-12-17 14:40:32 UTC
Session ID: 7567d6a9-a582-425f-a105-64846da7001d
Commit hash:
Build id: development
CrashReporter Key: 76ce1a57-7cd8-3005-9f78-5a0a16ec0167Crash
[INFO] at std::_shared_count<[__gnu_cxx::_Lock_policy]2>::shared_count[std::_weak_count<[__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::_shared_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2>::shared_ptr[std::_weak_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::shared_ptr<POIInstance>::shared_ptr[std::weak_ptr<POIInstance> const&, std::nothrow_t] (UnknownFile:?)
at std::weak_ptr<POIInstance>::lock[] const (UnknownFile:?)
at Village::getBedPOICount[] const (UnknownFile:?)
at Village::canRemove[] const (UnknownFile:?)
at VillageManager::_removeEligibleVillages[] (UnknownFile:?)
at VillageManager::tick[Tick const&] (UnknownFile:?)
at Dimension::tick[] (UnknownFile:?)
at Level::tick[] (UnknownFile:?)
at ServerLevel::tick[] (UnknownFile:?)
at GameSession::tick[] (UnknownFile:?)
at Minecraft::tickSimtime[int, int] (UnknownFile:?)
at Minecraft::update[] (UnknownFile:?)
at ServerInstance::_update[] (UnknownFile:?)
at clone (UnknownFile:?)Environment
Ubuntu 20.04.1 LTS
Linux craft 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
So this is odd - After using apt update;apt upgrade, make sure all my packages were the same, even forced installed all the packages between the two - still kept getting this disconnect on the unbuntu docker instance. As just a sanity check I downloaded the bedrock zip file again and told it to overwrite everything. Ran the server. IT IS WORKING. Unbelievable. Not sure what changed but I'm looking into it.
# wget https://minecraft.azureedge.net/bin-linux/bedrock-server-1.16.201.02.zip # unzip bedrock-server-1.16.201.02.zip # LD_LIBRARY_PATH=. ./bedrock_server No disconnects.... # md5sum ./bedrock_server 0cf91e624d9c7bfb98f6eac643829c85 ./bedrock_server # md5sum ./bedrock_server-1.16.201.02.orig 0cf91e624d9c7bfb98f6eac643829c85 ./bedrock_server-1.16.201.02.orig
Ran the following on my docker instance of itzg/minecraft-bedrock-server and I'll be damned it is working as well.
- $ docker exec -it bds_family5_1 bash
- # apt update
- # apt install wget
- # wget https://minecraft.azureedge.net/bin-linux/bedrock-server-1.16.201.02.zip
- # unzip bedrock-server-1.16.201.02.zip
- # mv bedrock_server-1.16.201.02 bedrock_server-1.16.201.02.orig
- # ln bedrock_server bedrock_server-1.16.201.02
- # exit
- $ docker-compose down
- $ docker-compose up -d family5
- Connected via client that was disconnecting 100% before.... no disconnects. No Segment Faults.
is duplicated by
relates to
is duplicated by
Right now I have only 1 user connecting to my server at a time, and the server crashes consistently within a minuet from the time any single user logs in, regardless of even if they move or not. All the users are at/near a village, but I don't even get enough time to teleport one away to test to see if the village is the cause.
I have support ticket open since the day the update was releases few weeks ago, and that they have not responded yet, and also there is this: BDS-10666
I wonder if the developers actually care at all to look into this at all or give a crap. I really do not trust a Windows server to be running this app, as my Linux is hardened and Minecraft BE server is contained in Linux in ways that it cannot be secured down in Windows. I'm not sure what the problem is here, are they not making enough money to maintain their software anymore?
There is one issue open here: BDS-10666 which seems to have more votes.
So far from what I have gathered this issue is exclusive to the worlds running in the Linux version of the dedicated server. Other users report that the same worlds work fine in Windows server and clients.
It seems like they screwed up something with the Linux version, and there is nothing we can do to fix this from our end (or at least there are no known solutions). Given that we have yet to get any response from the company on any of the support tickets and other report on this site, currently the known solutions are:
1. move to Windows server (not a viable option for me)
2. give up (there is nothing we can do if they do not want to support Linux version of the software, which is not surprising since the parent company that owns this product is known to be monopolistic).
I have nothing against MS or Mojang, it is just that I do not have the resource and time to fire up, configure, maintain, and secure a Windows server just for this one game.
Added some comments in BDS-10666.
tl;dr: using the test world attached to this bug, I can reliably reproduce the crash under Ubuntu 20.04 but have not been able to reproduce under Ubuntu 18.04. I believe the difference is the version of libstdc++ (6.0.25 on Ubuntu 18.04; 6.0.28 on Ubuntu 20.04).
I'm testing using a Docker container and the standard Ubuntu provided images (ubuntu:18.04 and ubuntu:20.04).
Can you try this and see if it fixes the crash for you?
Thanks for confirming. I've put some more detail on BDS-10666 with .so versions from my working install - can you compare these against your system?
My friend and I were using a bedrock server first to play together but BDS-11039 / BDS-10666 kicked in. Hoping realms will not have the same issue I've uploaded our world and started playing. I believe the very same issue haunts us on realm as well, after logging in (being in the middle of a village) the realm crashes and rolls back.
I've downloaded the world, and will try the workaround (which made bedrock server stable again) on realm too: removing all beds in the village(s) we're in currently. Locally the world doesn't make the app crash, so it is possible to do it. Once it's done and I've uploaded the world again, I'll let you know the results. If it will not disconnect us any more (as it does now always) then it must be the same bug as BDS-11039 / BDS-10666 tracks. Will see (tomorrow).
Thank you for your report!
We're actually already tracking this issue at BDS-10666, so we will resolve and link this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki
Thank you for your report!
We're actually already tracking this issue at BDS-10666, so we will resolve and link this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki
Thank you for your report!
We're going to be tracking this issue at BDS-10666, so we will resolve and link this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki
Thank you for your report!
We're actually already tracking this issue at BDS-10666, so we will resolve and link this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki
BDS-10666 points to an issue with the villager POI function. Are players near villages around the time a crash occurs?
Place enough/excess beds for the villagers to access. Does crashing still occur regularly?
Thank you for your report!
We're actually already tracking this issue at BDS-10666, so I will resolve and link this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki

I have the exact same problem, server starts and crashes after some time ( seemingly random, from seconds to minutes). Fresh install didn't fix the issue.
Version: 1.16.201.2
OS: Linux
Server start: 2020-12-21 20:04:54 CET
Dmp timestamp: 2020-12-21 20:05:42 CET
Upload Date: 2020-12-21 20:05:42 CET
Session ID: bdb2cb23-4434-43ea-9406-64ab616e789b
Commit hash:
Build id: development
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293
Crash
[INFO] at std::_shared_count<[__gnu_cxx::_Lock_policy]2>::shared_count[std::_weak_count<[__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::_shared_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2>::shared_ptr[std::_weak_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::shared_ptr<POIInstance>::shared_ptr[std::weak_ptr<POIInstance> const&, std::nothrow_t] (UnknownFile:?)
at std::weak_ptr<POIInstance>::lock[] const (UnknownFile:?)
at Village::getBedPOICount[] const (UnknownFile:?)
at Village::tick[Tick, BlockSource&] (UnknownFile:?)
at VillageManager::tickVillages[Tick const&, Vec3 const&, BlockSource&] (UnknownFile:?)
at ServerPlayer::tickWorld[Tick const&] (UnknownFile:?)
at std::function<bool [Player&]>::operator[][Player&] const (UnknownFile:?)
at Level::forEachPlayer[std::function<bool [Player&]>] (UnknownFile:?)
at Level::tick[] (UnknownFile:?)
at ServerLevel::tick[] (UnknownFile:?)
at GameSession::tick[] (UnknownFile:?)
at Minecraft::tickSimtime[int, int] (UnknownFile:?)
at Minecraft::update[] (UnknownFile:?)
at ServerInstance::_update[] (UnknownFile:?)
at clone (UnknownFile:?)
[2020-12-21 17:37:19 INFO] Starting Server
[2020-12-21 17:37:19 INFO] Version 1.16.201.2
[2020-12-21 17:37:19 INFO] Session ID f37976d5-9e3d-4505-9221-3fdf7f9484a0
[2020-12-21 17:37:19 INFO] Level Name: Bedrock level
[2020-12-21 17:37:19 INFO] Game mode: 0 Survival
[2020-12-21 17:37:19 INFO] Difficulty: 1 EASY
[INFO] opening worlds/Bedrock level/db
[INFO] IPv4 supported, port: 19132
[INFO] IPv6 supported, port: 19133
[INFO] IPv4 supported, port: 52520
[INFO] IPv6 supported, port: 49707
[INFO] Server started.
[INFO] Player connected: <removed>, xuid: <removed>
[INFO] Running AutoCompaction...
[INFO] Package: com.mojang.minecraft.dedicatedserver
Version: 1.16.201.2
OS: Linux
Server start: 2020-12-21 17:37:19 EST
Dmp timestamp: 2020-12-21 17:48:07 EST
Upload Date: 2020-12-21 17:48:07 EST
Session ID: f37976d5-9e3d-4505-9221-3fdf7f9484a0
Commit hash:
Build id: development
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293
Crash
[INFO] at std::_shared_count<[__gnu_cxx::_Lock_policy]2>::shared_count[std::_weak_count<[__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::_shared_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2>::shared_ptr[std::_weak_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::shared_ptr<POIInstance>::shared_ptr[std::weak_ptr<POIInstance> const&, std::nothrow_t] (UnknownFile:?)
at std::weak_ptr<POIInstance>::lock[] const (UnknownFile:?)
at Village::getBedPOICount[] const (UnknownFile:?)
at Village::tick[Tick, BlockSource&] (UnknownFile:?)
at VillageManager::tickVillages[Tick const&, Vec3 const&, BlockSource&] (UnknownFile:?)
at ServerPlayer::tickWorld[Tick const&] (UnknownFile:?)
at std::function<bool [Player&]>::operator[][Player&] const (UnknownFile:?)
at Level::forEachPlayer[std::function<bool [Player&]>] (UnknownFile:?)
at Level::tick[] (UnknownFile:?)
at ServerLevel::tick[] (UnknownFile:?)
at GameSession::tick[] (UnknownFile:?)
at Minecraft::tickSimtime[int, int] (UnknownFile:?)
at Minecraft::update[] (UnknownFile:?)
at ServerInstance::_update[] (UnknownFile:?)
at clone (UnknownFile:?)
I moved the Minecraft installation to the Ubuntu 18.04.5 LTS and for now seems to be fine.
I still do have the problem (also Ubuntu 18.04.5 LTS (GNU/Linux 4.15.0 x86_64)).
I was able to find a way to reproduce the bug.
Server crashes when i tab out of minecraft on win 10.
Lucky you guys that got it working. I have tried completely removing this off of my server and installing it again, and regardless of navigating away in Windows 10 or not it crashes with this output somewhere between few seconds to a couple of minuets from the time user logs in. I have also tried filling the form to get in touch with support but it has been several days and I have not heard anything back. I suspect they have no customer support at all.
That server has several other roles and services, so I'm not scrapping or reinstalling the entire Linux server just for this. This program is simply not worth it. If I could get my money back for the clients at this point I would have, and totally scrapped this garbage. We have had to already find something else to do anyways.
I am getting the same error and narrowed it down to just being my user that causes it to crash. It didn't matter if it was being accessed from a win10 client, Android device or an iOS device.
I took the world and loaded it as a local world to my win10 client where it won't crash but going to where the coordinates are that crash it on the server and I find a lot of quartz blocks missing. It is making me think the chunk in that area is corrupt.
I'm getting the same error on Ubuntu 20 server. I moved the world to Windows 10 server and it's working without problems (just a workaround if anyone interested).
I don't want to use win 10 just for that. Please fix it.
I did the same and moved it to a windows 10 machine and it is working with out problems as well. Before I moved it to windows 10 I moved it to CentOS 8 and it still crashed with the same errors.
Getting the exact same error on an Ubuntu 20 server here.
For what it's worth, I also have a similar issue and I opened a new ticket with a copy of the world where it happens and exact repro step (
BDS-10926).I managed to repro the issue 10 times in a row in the above ticket using a brand new user (one that had never logged in to that server before), so it's not related to the specific user.
I have the same issue, using dedicated Bedrock server on Linux, all players report getting disconnected after several minutes of playing, and the server console shows the same error. Seems to occur when invoking the Village:getBedPOICount function. This started earlier this week when the server was on version 1.16.200 – today I tried updating the server to 1.16.201.2 and the issue still persists.
Edit: FWIW, I am on Arch Linux (5.9.14-arch1-1), so it doesn't look like it is specific to Ubuntu/Debian systems.
[INFO] Package: com.mojang.minecraft.dedicatedserver
Version: 1.16.201.2
OS: Linux
Server start: 2020-12-31 11:42:33 JST
Dmp timestamp: 2020-12-31 20:27:31 JST
Upload Date: 2020-12-31 20:27:31 JST
Session ID: 6b0ceb56-2e05-4fd7-9603-a77bf7513b84
Commit hash:
Build id: development
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293
Crash
[INFO] at std::_shared_count<[__gnu_cxx::_Lock_policy]2>::shared_count[std::_weak_count<[__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::_shared_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2>::shared_ptr[std::_weak_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::shared_ptr<POIInstance>::shared_ptr[std::weak_ptr<POIInstance> const&, std::nothrow_t] (UnknownFile:?)
at std::weak_ptr<POIInstance>::lock[] const (UnknownFile:?)
at Village::getBedPOICount[] const (UnknownFile:?)
at Village::tick[Tick, BlockSource&] (UnknownFile:?)
at VillageManager::tickVillages[Tick const&, Vec3 const&, BlockSource&] (UnknownFile:?)
at ServerPlayer::tickWorld[Tick const&] (UnknownFile:?)
at std::function<bool [Player&]>::operator[][Player&] const (UnknownFile:?)
at Level::forEachPlayer[std::function<bool [Player&]>] (UnknownFile:?)
at Level::tick[] (UnknownFile:?)
at ServerLevel::tick[] (UnknownFile:?)
at GameSession::tick[] (UnknownFile:?)
at Minecraft::tickSimtime[int, int] (UnknownFile:?)
at Minecraft::update[] (UnknownFile:?)
at ServerInstance::_update[] (UnknownFile:?)
at clone (UnknownFile:?)
Just to help out dev here, there are number of tickets reporting same issue.
Related tickets:
BDS-10926(steps to reproduce and world attached)BDS-10777MCPE-111861MCPE-98133(One of the comment suggests issue might be with libc library version)Similar issue resolved in the past:
BDS-7551
Come on devs, fix it, we did the leg work for you
I'm having the same issue (client disconnects with UnknownFile java crash on the server side) using docker and the current itzg/minecraft-bedrock-server image (1.16.201.2). Tried running on a fresh download on a regular ubuntu server and with the world copied over had the same issue.
Interestingly if I copy the affected world to a windows 10 system and run as a client world it does not have problems! My next step is to try running a windows BDS server with the same world and see if it exhibits the problem. I'll keep isolating.
Ran the same world on the same windows version of the bedrock server and it does not exhibit the UnknownFile crash behavior.
Looks like this is specific to the linux server release 1.16.201.2. (at least in my case)
I'm checking on my libc version now to see if I can fix the problem with updating libc to the latest.
Thank you for testing this. This confirms that this is an issue with the application itself that the developers should be fixing. At least we are not wasting more time with this. I have yet to hear anything back from the support requests as well after many days.
If the developer doesn't fix/support the Linux version I will be completely dropping this game all together. I will not trust to move this application to a Windows box and then expose it to internet (not even willing to do it from behind a VPN). My installation in Linux is somewhat hardened to ensure this thing is contained and cannot mess with anything else. In Windows, even on a dedicated box/VM I don't trust to expose this to internet at all. Windows server is too costly and is too much of a pain to admin, configure, backup, etc... this is just not worth it at all. It's too bad, they are going to lose several customers (although I don't really think they care at this point, since they already got their money for Xbox live and the Windows 10 and Xbox clients).
Fresh install of ubuntu 20.04 still causes the issue. A temp workaround is to copy the world to a client or use the windows bedrock server which as Ali mentioned is not ideal for a number of reasons. Using the newer libc libraries did not help.
Details on the environment:
Sean, I think the suggestion about libc version was that you need to downgrade it, as issue started after updating the server.
Trying on not up-to-date Ubuntu 18 or similar could be a good test.
I've got a world that reliably crashes using bedrock-server 1.16.201.02 on Linux (Docker hosted). I've just tried with Ubuntu 18.04 (after an apt update/upgrade) and I've not been able to reproduce a crash.
In summary:
Ubuntu 21.04 (libc: 2.32): crashes
Ubuntu 20.04 (libc: 2.31): crashes
Ubuntu 18.04 (libc: 2.27): working so far
Please can someone else try using Ubuntu 18.04, confirm libc version and see if they can reproduce the crash.
confirm libc version with something like:
I moved my world to a system with Ubuntu 18.04.5 LTS with libc-2.27, installed bedrock server there, but it still crashes
I've done some more testing using the world files from
BDS-11039with Ubuntu 18.04 and Ubuntu 20.04.With this world I can reliably reproduce the crash under Ubuntu 20.04 following the instructions in that issue (teleport, walk around). That world has lots of villagers present in beds.
Under Ubuntu 18.04, I cannot reproduce the crash using that world.
I don't believe libc is the issue here - rather, potentially a behavioural change in libstdc+. The stack trace for this crash has std:: in the top few frames, which is provided by libstdc++ (aka GNU Standard C++ Library v3).
libstdc++ versions used in my tests:
Ubuntu 18.04: libstdc++.so.6.0.25
Ubuntu 20.04: libstdc++.so.6.0.28
Can you confirm what libstdc++ version you have present?
I should add - I'm testing using a Docker container and the standard Ubuntu provided images (ubuntu:18.04 and ubuntu:20.04).
My ubuntu 18.04 has
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
So both libs on our 18.04 systems are identical, yet the crash still occurs on my server while your 18.04 seems to work. I'm not running it in a docker container.
@Jelle Terpstra - thanks for checking.
Can you compare the output of ldd for the bedrock_server binary from my working 18.04 install with your setup?
This is the raw output:
This is the output with symlinks resolved:
I've also attached a screenshot comparing diffs of .so versions between working 18.04 install (on left) and broken 20.04 install (on right). (you may need to right click the image and view in a new tab to see all of it).
Ubuntu 20.04
linux-vdso.so.1 (0x00007ffd4bddf000)
libcurl.so.4 => /lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f45fa071000)
libCrypto.so => /home/leon/minecraftbe/bedrock/./libCrypto.so (0x00007f45f9e3a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f45f9e17000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f45f9e11000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f45f9d7e000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f45f9aa8000)
libstdc+.so.6 => /lib/x86_64-linux-gnu/libstdc+.so.6 (0x00007f45f98c5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f45f9776000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f45f975b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f45f9569000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4610485000)
libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f45f9540000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f45f951f000)
librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f45f94fd000)
libssh.so.4 => /lib/x86_64-linux-gnu/libssh.so.4 (0x00007f45f948f000)
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f45f947c000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f45f942f000)
libldap_r-2.4.so.2 => /lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f45f93d9000)
liblber-2.4.so.2 => /lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f45f93c8000)
libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f45f93b8000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f45f939c000)
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f45f921a000)
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f45f9044000)
libhogweed.so.5 => /lib/x86_64-linux-gnu/libhogweed.so.5 (0x00007f45f900c000)
libnettle.so.7 => /lib/x86_64-linux-gnu/libnettle.so.7 (0x00007f45f8fd0000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f45f8f4c000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f45f8e6f000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f45f8e3e000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f45f8e37000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f45f8e28000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f45f8e0a000)
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f45f8ded000)
libgssapi.so.3 => /lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f45f8da8000)
libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f45f8d85000)
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f45f8c4f000)
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f45f8c39000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f45f8c30000)
libheimntlm.so.0 => /lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f45f8c24000)
libkrb5.so.26 => /lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f45f8b91000)
libasn1.so.8 => /lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f45f8aea000)
libhcrypto.so.4 => /lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f45f8ab2000)
libroken.so.18 => /lib/x86_64-linux-gnu/libroken.so.18 (0x00007f45f8a97000)
libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007f45f8a8b000)
libwind.so.0 => /lib/x86_64-linux-gnu/libwind.so.0 (0x00007f45f8a61000)
libheimbase.so.1 => /lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f45f8a4f000)
libhx509.so.5 => /lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f45f8a01000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f45f88d6000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f45f889b000)
Here's my ldd output. I already diffed it with yours (Tom) and found no differences. I'm gonna test some more with the village that is causing the crash, it is only one of the villages in my world.
ok I was able to get a working version of the server. My process on the build was minimize the updating.
Next step is to "apt update; apt upgrade" to see of that causes issues. Normally it's one of the first things I do on a build. I did not upgrade on this build.
Commands I ran to get the ubuntu lxc running:
apt install wget wget https://minecraft.azureedge.net/bin-linux/bedrock-server-1.16.201.02.zip apt install unzip unzip *zip LD_LIBRARY_PATH=. ./bedrock_server Got a libcurl error apt install libcurl3 LD_LIBRARY_PATH=. ./bedrock_server Got a libssl error 1.1.1 needed apt update apt install libssl1.1 LD_LIBRARY_PATH=. ./bedrock_server Started running. Stopped. Copied world that is disconnecting into the worlds dir LD_LIBRARY_PATH=. ./bedrock_server Started running. Testing world - no disconnects occuring!Did a package update too. Among them was this one...
libc6:amd64 2.31-0ubuntu9 2.31-0ubuntu9.1
No crashes since.
We switched to realm where this issue seemed not happening, and worked fine for a while. But now it looks very similar there too. When my friend joins the realm crashes and rolls back. He's in a big village, and I'm suspecting it has to do with bed searching villagers and this bug.
Who could look at realm side logs?
I can confirm that I'm experiencing a very similar issue, my player is in a large village and the server disconnects / crashes within a minute or so of logging in. Journalctl output shows the Village::getBedPOICount[] const (UnknownFile:?) error line. It does seem like a recent system update could have caused the issue since I had updated very recently.
I ended up switching to the Windows version of BDS which doesn't have this issue. It also seems to run a lot better than the linux version in general (less bugs, chunk load times are much quicker, NPC's don't glitch out all the time, and it uses way less system resources). This is really unfortunate since I prefer to host the server using docker and not on a VM, but oh well. Hope the Mojang team can fix these issues soon!
Having looked at the error message and reviewed
BDS-11039(BDS-11039) I decided to try rebuilding a village that was destroyed and making sure that all villagers are near a village with enough beds for each villager. It might be coincidence and we've only played for an hour but we've not yet had a crash with this error message since.@slamdunx thanks for the info, it would be good to get an update on how your server is going after rebuilding the village.
Could this be a ticking entity problem? I've seen ways to fix this on other platforms but not for worlds on BDS.
This seems to be an issue with locking a weak_ptr. By debugging i've found, that the weak_ptr being locked is null, which causes a segfault. Since MSVC and gcc/clang have different implementations of the standard library, it might be related to that. I've seen that there is a null-check for a pointer, but only after locking. I believe this would be a simple fix, simply by checking for null before locking the weak_ptr.
You're probably right. That a null check can be so catastrophic tho...
@Jam approximately 5 hours of play since villagers had somewhere to sleep again and no server crashes to report. Hope it is something that can be fixed as easily as moving the null-pointer check and that it can be fixed across the whole code-base so that we don't find it elsewhere.
My question at this point is: is this site even being monitored by the developers at all?
If these people can't maintain their own software, they may either discontinue the product or just make the server opensource so people can fix this themselves. It has been over 5 weeks since they release the update. They have had enough time to start looking at the bug report. Maybe I'm misunderstanding something here... This site is where the bugs for the Minecraft Bedrock Edition Dedicated servers are reported to the developers, correct? or at least I was under the impression that this was the place... am I at the wrong place?
Need to get confirmation status changed to confirmed. Is there a verified way to reproduce this issue?
BDS-10926(which was closed as a duplicate of this bug) has a world file attached and repro steps to reliably reproduce the issue 100% of the time. It is very easy to confirm.Followed the steps. Did not crash.
Have the same issue - I can reproduce on demand. Some further clarity:
Running Bedrock 1.16.201.2 on Docker (on Windows)
Crash happens for any user but only when entering a certain area / within range of specific coordinates. Lowered the render distance from 10 to 6 chunks and was able to proceed further in a line before the crash and then respawned. Can fly around in a large circle without issue but then try to enter the circle and crash happens.
Version: 1.16.201.2
OS: Linux
Server start: 2021-01-27 03:06:06 UTC
Dmp timestamp: 2021-01-27 03:08:19 UTC
Upload Date: 2021-01-27 03:08:19 UTC
Session ID: 30a32c8b-77e3-456a-9a60-9627061922d8
Commit hash:
Build id: development
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293
Crash
[INFO] at std::_shared_count<[__gnu_cxx::_Lock_policy]2>::shared_count[std::_weak_count<[__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::_shared_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2>::shared_ptr[std::_weak_ptr<POIInstance, [__gnu_cxx::_Lock_policy]2> const&, std::nothrow_t] (UnknownFile:?)
at std::shared_ptr<POIInstance>::shared_ptr[std::weak_ptr<POIInstance> const&, std::nothrow_t] (UnknownFile:?)
at std::weak_ptr<POIInstance>::lock[] const (UnknownFile:?)
at Village::getBedPOICount[] const (UnknownFile:?)
at Village::tick[Tick, BlockSource&] (UnknownFile:?)
at VillageManager::tickVillages[Tick const&, Vec3 const&, BlockSource&] (UnknownFile:?)
at ServerPlayer::tickWorld[Tick const&] (UnknownFile:?)
at std::function<bool [Player&]>::operator[][Player&] const (UnknownFile:?)
at Level::forEachPlayer[std::function<bool [Player&]>] (UnknownFile:?)
at Level::tick[] (UnknownFile:?)
at ServerLevel::tick[] (UnknownFile:?)
at GameSession::tick[] (UnknownFile:?)
at Minecraft::tickSimtime[int, int] (UnknownFile:?)
at Minecraft::update[] (UnknownFile:?)
at ServerInstance::_update[] (UnknownFile:?)
at clone (UnknownFile:?)
@Joe Colafrancesco Can you attach the world files, your `server.properties` and your Dockerfile here? This would make it easier for the devs to reproduce.
I got the same crash with the same call stack reproducing when players were around our village (we made a village near our base). After one of the crashes, some of the villagers despawned. The world is too big to attach here, but here's my server.properties and the two Dockerfiles that I tried:
server.properties


Dockerfile_fedora
Dockerfile_ubuntu
I checked the server last night the world was corrupted and server was not working. The server has been offline (no access from users) but has been running. It seems like a couple of weeks ago the server somehow corrupted the world. I have nightly backups and restored the world from couple of weeks ago (after going back through several days of broken worlds) and everything is back to the way it was. This makes me wonder if a server crash, or the server just running idle by itself can actually corrupt the world. I guess I will find out in a couple of days that the server has been running to see if the world goes bad again. If that is the case this is yet another problem with this version.
server.properties
Pulled from latest itzg/minecraft-bedrock-server
Crash happens around village - near coordinates 539 68 208
World file - https://drive.google.com/drive/folders/1K2Ox7PXnxEkbP1Z0wygXqp2u3t3dlEpG?usp=sharing
We hit the issue on our Bedrock server as well, similar crash stack:
We did a bunch of testing, including killing off all villagers in the affected chunk, attempting to remove all beds - made no difference. The issue occurs in the chunk containing -1871, -2140, world files uploaded for testing purposes: https://drive.google.com/file/d/1egoKVwvqRxNqzu9LZ7j72UvQktkDHz9T/view?usp=sharing
Let me know if further testing and/or access is needed, we're not shy.
same as mine, it happened a week ago only in a specific village near my base(other villages is fine, we are managing 4 villages), i have tried switching servers and reinstalling ubuntu server 20.04 but it still causes the same issue and after several crashes it finally stopped then all of my villagers and traders near my base despawned even with the nametag RIP! right now im fine with no villagers than rebuilding all my structures
Also seeing this issue. First noticed it on Realms. Then stood up my own linux server and could see the error log, and it's the same issue as this. If any Mojang developer needs help reproducing please let me know. I have a world that reliably reproduces this issue.
thanks.
Had this crash as well on Linux server. I have a village chunk with 20+ beds, two of which are right next to each other.
Same world does not crash on Windows.
hey guys they just released a new version of the server, they said that the issues are fixed including this bug with the village
https://bugs.mojang.com/browse/REALMS-6812?focusedCommentId=917346&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-917346
We believe this issue is fixed in the server fix that went out yesterday - Bedrock Dedicated Server software 1.16.201.03, available at https://www.minecraft.net/en-us/download/server/bedrock/
After doing a quick test, the issue seems resolved. Will require further testing before I am convinced. Cautiously optimistic..
I tested my own use case that used to crash, and it also seems fixed. I will move into the cautiously optimistic camp also.
Testing here, looking good so far - chalk up one more 'seems fixed'. Thanks for addressing this! We had a rather large no-go zone in our world that we are glad to return to.
Same here – upgraded the BDS 2 days ago and things seem to be running OK so far. Thanks for the fix!
I pulled down a new server into my Docker environment, copied over the world files and can confirm that all looks good. No more crash that once was very consistent.
Not that everyone cares but I'm an IT geek - any way know what the issue was and what the fix was? Always love seeing some insight into the code and the fix for a bug!
Hey Joe, this is a closed source program. I doubt they are willing to discuss the issues and mistakes with their code.
This was eye-opening for me. It took them over two months to fix these issues while the admins toiled away in despair. People in this forum had done far more troubleshooting than they had to, and pointed to the exact problems, yet it took a long time for them to fix the code (or even respond to my support tickets with absolutely incompetent replies). If we could see the source code we could have had it fixed probably on the same day. We could probably address many long-standing performance issues with the product as well.
Additionally, to me, this means that I will be extremely careful and skeptical of products that are distributed via "Stores". Especially when the updates cannot be rolled back and are not optional. luckily this is just a stupid game and doesn't make a difference in life of most people. I have other products that I manage that I'm extremely worried about now.