Tom Gray

Tom Gray on BDS-11039 2021-01-10T10:54:04Z

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?

Tom Gray on BDS-10666 2021-01-10T10:51:33Z

@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:

linux-vdso.so.1 (0x00007ffc44b3d000)
	libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f4aa2cb0000)
	libCrypto.so => /app/libCrypto.so (0x00007f4aa2a79000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4aa285a000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4aa2656000)
	libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f4aa23c9000)
	libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f4aa1efe000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4aa1b75000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4aa17d7000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4aa15bf000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4aa11ce000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4ab92aa000)
	libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f4aa0fa9000)
	libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f4aa0d8c000)
	librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f4aa0b70000)
	libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f4aa0962000)
	libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f4aa0717000)
	libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f4aa04c5000)
	liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f4aa02b7000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4aa009a000)
	libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f4a9fd1c000)
	libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f4a9f9b6000)
	libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f4a9f782000)
	libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f4a9f54c000)
	libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f4a9f2cb000)
	libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f4a9eff5000)
	libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f4a9edc3000)
	libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f4a9ebbf000)
	libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f4a9e9b4000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f4a9e799000)
	libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f4a9e57e000)
	libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f4a9e33d000)
	libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f4a9e00e000)
	libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f4a9ddfb000)
	libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f4a9dbf7000)
	libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f4a9d9ee000)
	libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f4a9d761000)
	libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f4a9d4bf000)
	libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f4a9d289000)
	libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f4a9d073000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f4a9ce6b000)
	libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f4a9cc42000)
	libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f4a9ca33000)
	libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f4a9c7e9000)
	libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f4a9c4e0000)
	libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f4a9c2a8000)

This is the output with symlinks resolved:

for i in $(ldd bedrock_server | cut -f 3 -d ' '); do readlink $i; done

libcurl.so.4.5.0
libpthread-2.27.so
libdl-2.27.so
libstdc++.so.6.0.25
libm-2.27.so
libc-2.27.so
libnghttp2.so.14.15.2
libidn2.so.0.3.3
libpsl.so.5.2.0
libgssapi_krb5.so.2.2
libldap_r-2.4.so.2.10.8
liblber-2.4.so.2.10.8
libz.so.1.2.11
libunistring.so.2.1.0
libgnutls.so.30.14.10
libhogweed.so.4.4
libnettle.so.6.4
libgmp.so.10.3.2
libkrb5.so.3.3
libk5crypto.so.3.1
libcom_err.so.2.1
libkrb5support.so.0.1
libresolv-2.27.so
libsasl2.so.2.0.25
libgssapi.so.3.0.0
libp11-kit.so.0.3.0
libtasn1.so.6.5.5
libkeyutils.so.1.5
libheimntlm.so.0.1.0
libkrb5.so.26.0.0
libasn1.so.8.0.0
libhcrypto.so.4.1.0
libroken.so.18.1.0
libffi.so.6.0.4
libwind.so.0.0.0
libheimbase.so.1.0.0
libhx509.so.5.0.0
libsqlite3.so.0.8.6
libcrypt-2.27.so

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).

[media]

Tom Gray on BDS-10666 2021-01-09T07:55:01Z

I should add - I'm testing using a Docker container and the standard Ubuntu provided images (ubuntu:18.04 and ubuntu:20.04).

Tom Gray on BDS-11039 2021-01-09T07:54:13Z

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?

Tom Gray on BDS-10666 2021-01-09T07:51:38Z

I've done some more testing using the world files from BDS-11039 with 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?

Tom Gray on MCPE-98133 2021-01-08T19:08:18Z

Just added a comment to https://bugs.mojang.com/browse/BDS-10666, but tl;dr: I tried using Ubuntu 18.04 with libc 2.27 and have not yet been able to reproduce a crash.

Please can someone else try Ubuntu 18.04, confirm libc version and see if they can reproduce a crash?

Tom Gray on BDS-10666 2021-01-08T19:04:59Z

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:

nobody@14caa8275b4b:/app$ ls -al /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 Jun  4  2020 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.27.so

Tom Gray on MCPE-98133 2021-01-03T18:47:24Z

Affects 1.16.201.2 (latest as of writing):

[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:?)

Appears to happen during daytime and nighttime. Server only been experiencing since upgrade from 1.16.101.01 to 1.16.201.02, but this may be caused by actions of players on this server (more players working on a village that contains villagers and beds).

Confirmed occurs on different versions of libc - Ubuntu LTS (20.04): libc6 2.31; Ubuntu current (21.04): libc6: 2.32.

Tom Gray

Assigned

Reported

Comments