Trinitycore: [Crash] MapInstanced::DestroyInstance

[sucklifex]

http://paste.ubuntu.com/23143523

Branch(es): 3.3.5
TC hash/commit: 5868509a6366d0ba7a0fe819c3ece0e4a57c7029
TDB version: 61
Operating system: Debian

[Aokromes]

plz, for future reports don't use simply crash for title, that makes search feature useless when trying to find if it's duplicate of another ticket.

[Aokromes]

AND again, update your core before reporting bugs.

[jackpoz]

if we trust local values, this is a NULL dereference crash inside std::list destructor. It happened when destroying an instance.

Do Unit.cpp or Unit.h have any custom change ? could you post the files ?

[sucklifex]

@jackpoz
unit.h http://paste.ubuntu.com/23145338/
part 1 unit.cpp http://paste.ubuntu.com/23145350/
part 2 unit.cpp http://paste.ubuntu.com/23145354/

@Aokromes new updates are unstable too many range issue ...

[Aokromes]

1st rule when reporting bugs, and even more when reporting crashes:

• Update your core before reporting a bug, the bug of ancient cores can be fixed on newer cores.

https://community.trinitycore.org/topic/37-the-trinitycore-issuetracker-and-you/

[jackpoz]

what's the if (!m_sharedVision.empty()) code in Unit::~Unit() doing ?

[jackpoz]

@Aokromes 1 month and a half is "ancient core" ?

[Aokromes]

with all the changes we had on august, yes.

[jackpoz]

nah, half of commits were build fixes, I strongly doubt any of the commits fixed any old crash, even less this one.

What is interesting about this crash is that Unit* is 0x7fff7d16d000 and std::list* is 0x7fff7d16dc58 so we can get the crashing Unit member as pointer diff (which is 0xc58 bytes after the start of Unit class)

[Aokromes]

anyway, those rules are the rules, for every report, not a recent invention.

[jackpoz]

from the forum

• Ancient revisions, when reporting a bug please update at least to the current TDB version.

https://github.com/TrinityCore/TrinityCore/commit/5868509a6366d0ba7a0fe819c3ece0e4a57c7029 is more recent than current TDB version.

[Aokromes]

From forum too:

And now some additional information:

• Make sure you are running on the latest revision of the source (we are constantly pushing changes, so your issue might have been resolved already)

[jackpoz]

lol, such clear rules stating different things. let's close all issues opened yesterday because we pushed 1 commit.
good luck reproducing a race condition crash on latest revision in time before anyone pushes another commit!

[Aokromes]

we had 294 commits, 551 files changed on 6 weeks, there is no good reason to have one core older than 1 week unless it's having constant crashes, and if it has constant crashes, welcome tickets of those.

[jackpoz]

@sucklifex did you paste twice the same Unit.h on pastebin or is it the actual file being duplicated ? pushing the whole repo would be easier.

[jackpoz]

@Aokromes you have no clue about what this crash is about, please let people who know what they are doing work. The most important thing is to fix crashes in TC code, not to scare away users who are actually contributing by reporting crashes.

[nawuko]

You guys are so cute :heart:

[sucklifex]

@jackpoz It's duplicated because of double ctrl + c, give me your email, i will sends my whole custom scripts, as .diff

also another instance crash log: http://paste.ubuntu.com/23147017/

[jackpoz]

better make the diff public so everyone can help with the crash.

the new crashlog has the same key as https://github.com/TrinityCore/TrinityCore/issues/17910#issuecomment-244967592 .

it's very strange that it crashes with the same map and difficulty, that's probably always the same bucket in the std::hashtable. it would be really nice to get a crashlog with no custom changes and default build flags (no fancy GCC custom flags) to exclude possible weird behaviors of these 2 things.

[Aokromes]

Still no answer to jackpoz's request

[sucklifex]

Not happens for a while