-
Bug
-
Resolution: Duplicate
-
None
-
1.16.201 Hotfix
-
None
-
Debian GNU/Linux 10 (buster), glibc version 2.28-10, Linux kernel 4.19.0-13-amd64
-
Unconfirmed
-
457993
To reproduce:
1. Stand at the position 1695 36 -953 and wait (in the world here).
2. Game Crashes.
The following crash log was produced on the server:
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:?)
From what I have discovered, this bug is caused by locking a weak_ptr from the POIInstance list (std::vector<std::weak_ptr<POIInstance>>). When reading from the vector using [], a null value is returned, which ultimately gets dereferenced and causes a crash. To be exact, the address+8 is dereferenced, which to my knowledge is the offset for the reference count of a smart pointer.
I can also see that right after locking the weak_ptr, there is some kind of null check (not sure if its for the same pointer though, I think not).
I propose the following: before locking the weak_ptr, check if it is nullptr. If not, then you can lock it. I don't know why any of the POIInstances should ever be nullpointers, but simply checking for this could solve the issue.
- duplicates
-
- Resolved
