Many Crash on mangos-0.12 - Linux Debian x64

[Auntie Mangos]

It doesn't work, I've to use my first idea : http://getmangos.eu/community/viewtopic.php?id=14582&p=119482&viewfull=1#post119482

And it doesn't crash now, but I dislike this fix

[Milk13]

Hi,

I updated my core 3 days ago, and I get many crashs, about one crash / hour.

These report are the last, that I got.

http://pastebin.com/zer19UdG

http://pastebin.com/xfqfgDtj

http://pastebin.com/Yub7pQwG

http://pastebin.com/usDqSZCx

http://pastebin.com/CRA7Lk4k

The problem is that the function void Map::SendObjectUpdates()

call the function obj->BuildUpdateData(update_players);

but obj is not detect as an WorldObject, but as a simple Object,

but the core said "Unexpected call of Object::BuildUpdateData for object (TypeId: 4 Update fields: 1592)"

Thx to help me.

[Milk13]

It can be this commit : http://github.com/mangos/mangos/commit/2fc3f595e88d9d9a9b25f44482fe74d22d01daec

that make the problem.

[VladimirMangos]

Hmm, TYPEID_PLAYER = 4,\\

This only possible if Player object deleted at call moment.

In [s0011]

I backport single found not backported commit with crash fix. I not sure that this help.

[Milk13]

I will try, thx.

If it doesn't work, I will try this patch :

diff --git a/src/game/Map.cpp b/src/game/Map.cpp

index 6d54b79..5efb7ff 100644

--- a/src/game/Map.cpp

+++ b/src/game/Map.cpp

@@ -3398,7 +3398,19 @@ void Map::SendObjectUpdates()

i_objectsToClientUpdate.erase(i_objectsToClientUpdate.begin());

if (!obj)

continue;

- obj->BuildUpdateData(update_players);

+switch(obj->GetTypeId())

+{

+case TYPEID_ITEM:

+case TYPEID_CONTAINER:

+ ((Item*)obj)->BuildUpdateData(update_players); break;

+case TYPEID_UNIT:

+case TYPEID_PLAYER:

+case TYPEID_GAMEOBJECT:

+case TYPEID_DYNAMICOBJECT:

+case TYPEID_CORPSE:

+ ((WorldObject*)obj)->BuildUpdateData(update_players); break;

+default: continue;

+}

}

WorldPacket packet; // here we allocate a std::vector with a size of 0x10000

diff --git a/src/game/Object.cpp b/src/game/Object.cpp

index b9b5ee7..107f9c5 100644

--- a/src/game/Object.cpp

+++ b/src/game/Object.cpp

@@ -1047,11 +1047,11 @@ void Object::RemoveFromClientUpdateList()

ASSERT(false);

}

-void Object::BuildUpdateData( UpdateDataMapType& update_players)

+/*void Object::BuildUpdateData( UpdateDataMapType& update_players)

{

sLog.outError("Unexpected call of Object::BuildUpdateData for object (TypeId: %u Update fields: %u GUID: %u GUIDLow: %u)",GetTypeId(), m_valuesCount, GetGUID(), GetGUIDLow());

ASSERT(false);

-}

+}*/

WorldObject::WorldObject()

: m_isActiveObject(false), m_currMap(NULL), m_zoneScript(NULL), m_mapId(0), m_InstanceId(0),

diff --git a/src/game/Object.h b/src/game/Object.h

index f966e69..74238a2 100644

--- a/src/game/Object.h

+++ b/src/game/Object.h

@@ -129,7 +129,7 @@ class MANGOS_DLL_SPEC Object

// must be overwrite in appropriate subclasses (WorldObject, Item currently), or will crash

virtual void AddToClientUpdateList();

virtual void RemoveFromClientUpdateList();

- virtual void BuildUpdateData(UpdateDataMapType& update_players);

+ //virtual void BuildUpdateData(UpdateDataMapType& update_players);

void BuildValuesUpdateBlockForPlayer( UpdateData *data, Player *target ) const;

void BuildOutOfRangeUpdateBlock( UpdateData *data ) const;

[Milk13]

The last crash return this : Unexpected call of Object::BuildUpdateData for object (TypeId: 4 Update fields: 1592 GUID: 3500695680 GUIDLow: 3500695680)

But there is no player with this GUID, the pointer is certainly corrupted.

[VladimirMangos]

You patch will low help. Maybe it will not crash by send corrupted data to client and crash clients. or crash later

Because Object:: version retunr typeid then in same way switch(obj->GetTypeId()) will use this value for seelction.

Corrupted data just will not detected at this point and will showup own affects later..

Need find why deleted object pointer still listed in update list.

As i say it crash or deleted player pointer, and ofc old memory when Player object has been placed can be corrupted at time access. But pointer itself must be not corrupted.

maybe if add output pointer value in ~Player to log with name and at crash case will can be possible catch what player has been affected and ask user about what he do at crash time...

[Milk13]

I think this patch is better to check the integrity of the pointer :

diff --git a/src/game/Map.cpp b/src/game/Map.cpp

index 6d54b79..e73ad8d 100644

--- a/src/game/Map.cpp

+++ b/src/game/Map.cpp

@@ -3398,6 +3398,11 @@ void Map::SendObjectUpdates()

i_objectsToClientUpdate.erase(i_objectsToClientUpdate.begin());

+ if(obj->GetTypeId() == TYPEID_PLAYER && !sObjectMgr.GetPlayer(obj->GetGUIDLow()))

+ {

+ sLog.outError("Map::SendObjectUpdates : no player found");

+ continue;

+ }

obj->BuildUpdateData(update_players);

}

[VladimirMangos]

as you want. Because in any form this is not for core repo. Just hack (why use sure that next time deleted player will not have corrupted typeid field also...) prevent crash in single show up case. and _hide_ possibility find problem.

[Milk13]

The crash is still here, with your commit, and my last patch. It's the same. I've not try my first idea.

Maybe, the crash can come from the gcc flags that I use : "-march=native -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -m64 -pipe -msse4.2 -DFD_SETSIZE=4096 -fno-delete-null-pointer-checks -fno-strength-reduce -fno-strict-aliasing -frename-registers -pipe" ?

[polonawa]

I had the same crash on my custom core, and i found that it was due to an assertion fail , enven if the backtrace didn't mentionned it.

Polymorphism makes the core call Object::BuildUpdateData() instead of WorldObject::BuildUpdateData() in several cases I've not identified yet.

To prevent thoses crashes an hacky way, you can comment the assert in Object.cpp (around line 1130)

void Object::BuildUpdateData( UpdateDataMapType& /*update_players */)
{
   sLog.outError("Unexpected call of Object::BuildUpdateData for object (TypeId: %u Update fields: %u)",GetTypeId(), m_valuesCount);
   //ASSERT(false);
}

[FragFrog]

If it helps: I'm currently testing one of the latest pre-tbc-revision cores, haven't had a crash in the past few days yet on our testserver running a 32bit windows compile. Of course, that is only with a dozen testers, a full server might be a bit less stable.

[crashuncle]

I had the same crash on my custom core, and i found that it was due to an assertion fail , enven if the backtrace didn't mentionned it.

Polymorphism makes the core call Object::BuildUpdateData() instead of WorldObject::BuildUpdateData() in several cases I've not identified yet.

To prevent thoses crashes an hacky way, you can comment the assert in Object.cpp (around line 1130)

void Object::BuildUpdateData( UpdateDataMapType& /*update_players */)
{
   sLog.outError("Unexpected call of Object::BuildUpdateData for object (TypeId: %u Update fields: %u)",GetTypeId(), m_valuesCount);
   //ASSERT(false);
}

Has this issue been fixed yet?

[Casso]

I used your "first idea" but i get similar crashlog (Crashed at Object::BuildValuesUpdateBlockForPlayer+11C, but in call tree is Map::SendObjectUpdates+129 ...)

I used hacky method with try/catch blocks in while loop of SendObjectUpdates, and it looks fine.

Your idea replaced by my method: http://github.com/casso/Mysteria6928/commit/dd6e67a8b9b7e59d2a0007d9d8dfdb69fa53e6c1

My server: windows server 2003R2 x64 and mangos-0.12 rev 8569

Sorry my english, I'm from slovakia

[Flemzard]

This crash was been fix with this

(in map.cpp)

{

Object* obj = *i_objectsToClientUpdate.begin();

i_objectsToClientUpdate.erase(i_objectsToClientUpdate.begin());

- obj->BuildUpdateData(update_players);

+ if (obj && obj->IsInWorld())

+ switch(obj->GetTypeId())

+ {

+ case TYPEID_ITEM:

+ case TYPEID_CONTAINER:

+ ((Item*)obj)->BuildUpdateData(update_players);

+ break;

+ case TYPEID_PLAYER:

+ if(!(obj->GetGUIDLow() != 0 && sObjectMgr.GetPlayer(obj->GetGUIDLow())))

+ break;

+ case TYPEID_UNIT:

+ case TYPEID_GAMEOBJECT:

+ case TYPEID_DYNAMICOBJECT:

+ case TYPEID_CORPSE:

+ ((WorldObject*)obj)->BuildUpdateData(update_players);

+ break;

+ default: break;

+ }

}

[Atari007]

This crash was been fix with this

Works fine. Thanks!

[Flemzard]

You're welcome

[Raynar]

This crash was been fix with this

This fix is GOD!

[crashuncle]

I wonder why this hasn't been added in the core repo yet?

[Toinan67]

Because :

You patch will low help. Maybe it will not crash by send corrupted data to client and crash clients. or crash later

Because Object:: version retunr typeid then in same way switch(obj->GetTypeId()) will use this value for seelction.

Corrupted data just will not detected at this point and will showup own affects later..

Need find why deleted object pointer still listed in update list.

And :

as you want. Because in any form this is not for core repo. Just hack (why use sure that next time deleted player will not have corrupted typeid field also...) prevent crash in single show up case. and _hide_ possibility find problem.