[DiscordArchive] This may be a weird question but why is Slam implemented like it is in Azeroth Core?
[DiscordArchive] This may be a weird question but why is Slam implemented like it is in Azeroth Core?
Original source
This may be a weird question but why is Slam implemented like it is in Azeroth Core?
Is there a specific reason why Slam needs to be a dummy spell which then in scripts applies the actual spell which hits the target?
rektbyfaith
01-09-2025, 11:32 AM #1Archived author: Awakened • Posted: 2025-01-09T11:32:50.951000+00:00
Original source
This may be a weird question but why is Slam implemented like it is in Azeroth Core?
Is there a specific reason why Slam needs to be a dummy spell which then in scripts applies the actual spell which hits the target?
Original source
Because that's likely how it was observed to work on official servers
rektbyfaith
01-09-2025, 11:35 AM #2Archived author: Bench • Posted: 2025-01-09T11:35:38.162000+00:00
Original source
Because that's likely how it was observed to work on official servers
Original source
Ah I actually checked wowhead WOTLK now and yeah, it is dummy + server side script
I was looking at classic wowhead where it's just weapon damage and I was confused
Sometimes I forget acore is wotlk because I want to do classic+ stuff in it
rektbyfaith
01-09-2025, 11:41 AM #3Archived author: Awakened • Posted: 2025-01-09T11:41:26.569000+00:00
Original source
Ah I actually checked wowhead WOTLK now and yeah, it is dummy + server side script
I was looking at classic wowhead where it's just weapon damage and I was confused
Sometimes I forget acore is wotlk because I want to do classic+ stuff in it
Original source
Build a simple tool to test the hypothesis with a dangling player pointer. It seems that is the case:
```
2025-01-09 11:09:26 !!!!!!Player with pointer 0x7fff69a74e00 already deleted, using dangling pointer!!! Player: 50467. Map: 0, x:-9279.154, y:-2266.622, z:67.347.
Deleted at:
./worldserver(+0xcb80a9) [0x55555620c0a9]
./worldserver(DebugRegistry::RecordPlayerDelete(Player*)) [0x55555625b58f]
./worldserver(Player::~Player() + 32) [0x55555620d860]
./worldserver(Player::~Player() + 9) [0x55555620e799]
./worldserver(Map::RemovePlayerFromMap(Player*, bool) + 199) [0x5555564bd097]
./worldserver(WorldSession::LogoutPlayer(bool) + 2314) [0x5555565877fa]
./worldserver(WorldSession::Update(unsigned int, PacketFilter&) + 7807) [0x55555658a88f]
./worldserver(World::UpdateSessions(unsigned int) + 668) [0x55555676928c]
./worldserver(World::Update(unsigned int) + 1082) [0x55555676346a]
./worldserver(+0x4bc793) [0x555555a10793]
./worldserver(+0x4b824f) [0x555555a0c24f]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7ffff6cc6d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7ffff6cc6e40]
./worldserver(+0x4b6995) [0x555555a0a995]
Using here:
./worldserver(+0xcb80a9) [0x55555620c0a9]
./worldserver(DebugRegistry::ValidatePlayerPointer(Player*) + 339) [0x5555562ae263]
./worldserver(Player::Update(unsigned int) + 319) [0x5555562a5faf]
./worldserver(Map::Update(unsigned int, unsigned int, bool) + 1563) [0x5555564bb7cb]
./worldserver(MapUpdateRequest::call() + 66) [0x5555564d1952]
./worldserver(+0xf7d428) [0x5555564d1428]
/lib/x86_64-linux-gnu/libstdc++.so.6(+0xdc253) [0x7ffff70a9253]
/lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7ffff6d31ac3]
/lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7ffff6dc3850]
```
But so far, I haven't been able to figure out why, in some rare cases, a "valid" player pointer is still in m_mapRefMgr after player deletion.
rektbyfaith
01-09-2025, 12:43 PM #4Archived author: walkline • Posted: 2025-01-09T12:43:13.691000+00:00
Original source
Build a simple tool to test the hypothesis with a dangling player pointer. It seems that is the case:
```
2025-01-09 11:09:26 !!!!!!Player with pointer 0x7fff69a74e00 already deleted, using dangling pointer!!! Player: 50467. Map: 0, x:-9279.154, y:-2266.622, z:67.347.
Deleted at:
./worldserver(+0xcb80a9) [0x55555620c0a9]
./worldserver(DebugRegistry::RecordPlayerDelete(Player*)) [0x55555625b58f]
./worldserver(Player::~Player() + 32) [0x55555620d860]
./worldserver(Player::~Player() + 9) [0x55555620e799]
./worldserver(Map::RemovePlayerFromMap(Player*, bool) + 199) [0x5555564bd097]
./worldserver(WorldSession::LogoutPlayer(bool) + 2314) [0x5555565877fa]
./worldserver(WorldSession::Update(unsigned int, PacketFilter&) + 7807) [0x55555658a88f]
./worldserver(World::UpdateSessions(unsigned int) + 668) [0x55555676928c]
./worldserver(World::Update(unsigned int) + 1082) [0x55555676346a]
./worldserver(+0x4bc793) [0x555555a10793]
./worldserver(+0x4b824f) [0x555555a0c24f]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7ffff6cc6d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7ffff6cc6e40]
./worldserver(+0x4b6995) [0x555555a0a995]
Using here:
./worldserver(+0xcb80a9) [0x55555620c0a9]
./worldserver(DebugRegistry::ValidatePlayerPointer(Player*) + 339) [0x5555562ae263]
./worldserver(Player::Update(unsigned int) + 319) [0x5555562a5faf]
./worldserver(Map::Update(unsigned int, unsigned int, bool) + 1563) [0x5555564bb7cb]
./worldserver(MapUpdateRequest::call() + 66) [0x5555564d1952]
./worldserver(+0xf7d428) [0x5555564d1428]
/lib/x86_64-linux-gnu/libstdc++.so.6(+0xdc253) [0x7ffff70a9253]
/lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7ffff6d31ac3]
/lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7ffff6dc3850]
```
But so far, I haven't been able to figure out why, in some rare cases, a "valid" player pointer is still in m_mapRefMgr after player deletion.
Original source
For which crashlogs
rektbyfaith
01-09-2025, 02:24 PM #5Archived author: Takenbacon • Posted: 2025-01-09T14:24:05.700000+00:00
Original source
For which crashlogs
Original source
I think this crash reflects the issue - https://gist.github.com/Nyeriah/11365392...a0d6493d32
But I suppose not all of these dangling pointer usages lead to crashes.
rektbyfaith
01-09-2025, 02:28 PM #6Archived author: walkline • Posted: 2025-01-09T14:28:32.125000+00:00
Original source
I think this crash reflects the issue - https://gist.github.com/Nyeriah/11365392...a0d6493d32
But I suppose not all of these dangling pointer usages lead to crashes.
1 Guest(s)
1 Guest(s)