"CanEnter" - Map Related Server Crash

I will take that zeppelin today and see if I can reproduce the issue.

I can confirm this. Crash and backtrace follow.
[code]
Player: channels cleaned up!
Aura 22 now is remove mode 5
Aura 42 now is remove mode 5
Aura 22 now is remove mode 5
Aura 42 now is remove mode 5
Aura 22 now is remove mode 5
Aura 42 now is remove mode 5
Aura 22 now is remove mode 5
Aura 42 now is remove mode 5
Aura 22 now is remove mode 5
Aura 42 now is remove mode 5
Aura 22 now is remove mode 5
Aura 42 now is remove mode 5
Aura 22 now is remove mode 5
Aura 42 now is remove mode 5
Aura 22 now is remove mode 5
Aura 42 now is remove mode 5
Aura 22 now is remove mode 5
Aura 42 now is remove mode 5
WORLD: Received opcode CMSG_ZONEUPDATE: newzone is 33
STORAGE: DestroyZoneLimitedItem in map 0 and area 33
Player: channels cleaned up!
Map::CanEnter -Player Marrek (Guid: 3) already in map!
/home/---/zero/src/server/src/game/Map.cpp:1600: Error: Assertion in CanEnter
failed: false
Stack Trace:
/home/---/zero/bin/mangosd(_ZN6Player10TeleportToEjffffjPK11AreaTrigger+0x580) [0x86ec648]
/home/---/zero/bin/mangosd(_ZN9Transport17TeleportTransportEjfff+0x13c) [0x88d16d8]
/home/---/zero/bin/mangosd(_ZN9Transport6UpdateEjj+0x106) [0x88d19ec]
/home/---/zero/bin/mangosd(_ZN11WorldObject12UpdateHelper6UpdateEj+0x3a) [0x881e836]
/home/---/zero/bin/mangosd(_ZN10MapManager6UpdateEj+0x10b) [0x885269f]
/home/---/zero/bin/mangosd(_ZN5World6UpdateEj+0x313) [0x88e2a8d]
/home/---/zero/bin/mangosd(_ZN13WorldRunnable3runEv+0x4f) [0x854dc0f]
/home/---/zero/bin/mangosd(_ZN9ACE_Based6Thread10ThreadTaskEPv+0x29) [0x8972c39]
/usr/lib/libACE-6.0.3.so(_ZN21ACE_OS_Thread_Adapter6invokeEv+0xb1) [0xb7f50171]
/usr/lib/libACE-6.0.3.so(ace_thread_adapter+0xf) [0xb7f121cf]
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0(+0x5c39) [0xb77d6c39]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(clone+0x5e) [0xb7743a6e]
mangosd: /home/---/zero/src/server/src/game/Map.cpp:1600: virtual bool Map::CanEnter(Player*): Assertion `"false" && 0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb20f3b70 (LWP 8374)]
0xb7fe1424 in __kernel_vsyscall ()
(gdb) backtrace
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7697681 in raise () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#2 0xb769aab2 in abort () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#3 0xb7690898 in __assert_fail () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#4 0x0884198d in Map::CanEnter (this=0xb99ef90, player=0xd15f150)
at /home/---/zero/src/server/src/game/Map.cpp:1600
#5 0x086ec648 in Player::TeleportTo (this=0xd15f150, mapid=0, x=-11372.6543,
y=-402.066406, z=214.894485, orientation=1, options=2, at=0x0)
at /home/---/zero/src/server/src/game/Player.cpp:1616
#6 0x088d16d8 in Transport::TeleportTransport (this=0xa4d2c88, newMapid=0,
x=-11372.6543, y=-402.066406, z=214.894485)
at /home/---/zero/src/server/src/game/Transports.cpp:462
#7 0x088d19ec in Transport::Update (this=0xa4d2c88)
at /home/---/zero/src/server/src/game/Transports.cpp:512
#8 0x0881e836 in WorldObject::UpdateHelper::Update (this=0xb20f3228,
time_diff=100) at /home/---/zero/src/server/src/game/Object.h:473
#9 0x0885269f in MapManager::Update (this=0xb2f0d28, diff=49)
at /home/---/zero/src/server/src/game/MapManager.cpp:189
#10 0x088e2a8d in World::Update (this=0x8cdb348, diff=49)
at /home/---/zero/src/server/src/game/World.cpp:1496
#11 0x0854dc0f in WorldRunnable::run (this=0xa4e43d8)
at /home/---/zero/src/server/src/mangosd/WorldRunnable.cpp:66
#12 0x08972c39 in ACE_Based::Thread::ThreadTask (param=0xa4e43d8)
at /home/---/zero/src/server/src/shared/Threading.cpp:197
#13 0xb7f50171 in ACE_OS_Thread_Adapter::invoke() ()
from /usr/lib/libACE-6.0.3.so
#14 0xb7f121cf in ace_thread_adapter () from /usr/lib/libACE-6.0.3.so
#15 0xb77d6c39 in start_thread ()
from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#16 0xb7743a6e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
[/code]
Does not appear to happen on all zeppelins.

Have now logged this crash on Covenant-Wow.

From internal team discussions:

[QUOTE]The cause of the crash is due to the assert and the function CanEnter not taking the possibility of a player moving to and from the same map
It's saying if OldMap == NewMap then assert
[/QUOTE]
[IMG]https://www.getmangos.eu/attachment.php?attachmentid=140[/IMG]

As far as I see it the entire CanEnter function, as it stands, is completely pointless. The only thing it checks is if the old map is the same as the new map, then assert. This makes no sense, and I know of several times where this would be true. Either we need to check if the player is on a transport within the CanEnter, or it needs to be "removed".

That being said, CanEnter would be required for, as an example, TBC flagged accounts in WoTLK. It would need to be rewritten obviously, but if you tried to take the boat from Stormwind to Borean Tundra in WoTLK with a TBC account, it would teleport you back to the dock and tell you that your account is not eligible to be in any WoTLK areas.

Issue moved to confirmed status with milestone of Rel20. Discussions are taking place how to fix it and it will be done asap.

I suggest something along these lines

[code]bool Map::CanEnter(Player* player){
if (player->GetMapRef().getTarget() == this)
{
// Check if player is on a transport or not. Prevents crashes on transports like Zeppelines with dest. on the same map
if (player->HasMovementFlag(MOVEFLAG_ONTRANSPORT))
{
return true;
}
else
{
sLog.outError("Map::CanEnter -%s already in map!", player->GetGuidStr().c_str());
MANGOS_ASSERT(false);
return false;
}
}


return true;
}[/code]

Commit of possible fix - [url]https://github.com/mangoszero/server/commit/0a6355d15c451ccb8ae174b756048bf67ea62ff3[/url]
In testing on covenant shortly.

Confirmed this is fixed in the above commit. Closing this issue now and marking as resolved.

Causing issues on mac clients

From conversation with Antz:

[01.10.14 10:40:50] SHUYΛ: now we got a different issue on mac clients
[01.10.14 10:41:07] SHUYΛ: at leasts it's not crashing the server
[01.10.14 10:41:49] SHUYΛ: but on the mac client, it's getting into the loading screen from grom'gol to UC... then you fall down from the zepp after the loading screen right before duskwood (where the loading screen started).
[01.10.14 10:42:04] SHUYΛ: So with a Mac Client it would be never possible to get to UC from grom'gol

I know, that there was always an issue with transports before for mac clients. It felt like the map got loaded before the zeppelin itself after the loading screen, so you always fall down - but you fall down at least in the new zone and could run/swim the last mile.

Okay, other transports are working like before (falling down after the loading screen but in the correct and new zone).
For Grom'gol to Undercity, this is not working. You fall down in Stranglethorn Vale right after the loading screen in the same old zone (should fall down in the new zone at least).

I remember this happening on Mac clients on official. I had a friend who was trying Apple at the time and we all knew when he fell. We'd here cursing on TeamSpeak and everybody would laugh. However, I seem to recall it affecting all zeppelins, though I may be wrong.

The crash fix is not related to the player not being ported to the correct location. This should be posted as a separate issue to prevent confusion and preserve proper issue history :)