Core Dumb BackTrace + More

[krich]

Guys,

I'm experiencing the same thing.

I suspected that this debug statement was crashing the zone by referencing a null pointer (either sender, mob, or mobTarget). I put a statement in front of that debug statement that prints out the pointer values of sender, mob, and mobTarget (major log spam). Like this:

LogFile->write(EQEMuLog::Debug, "Check aggro for %d assisting %d, target %d.", sender, mob, mobTarget);

When the zone crashes, mobTarget shows a value of 0. Like this:

eqemu_debug_zone.log:16325 [11.10. - 23:51:16] Check aggro for 136602560 assisting 136762384, target 0.

Now, this is very strange because the previous IF statement checks to make sure mobTarget is not null, so in order to get into that block of code mobTarget cannot be null. Here's the full block of code:

                if (mobTarget
                        && (fv <= FACTION_AMIABLE
#ifdef GUILDWARS
                        || guildwars.GetCurrentGuildFaction(mob,sender) >= GW_KINDLY
#endif
                        )
                                && (mob->IsNPC() && mob->IsEngaged()) || (mob->IsClient() && mob->CastToClient()->AutoAttackEnabled()) // Clients do not use IsEngaged!!
                                && dist <= iAssistRange
                                && (mob->GetINT() <= 100 || mobTarget->GetLevelCon(sender->GetLevel()) != CON_GREEN)
                                && dist <= (iAssistRange * 2)
                                ) {
                                // Had an if statement to check if it wasn't a GM but theres no reason, we check that above
                                // Also had an interactive npc check but I believe these are no longer used, if required can be put above
                                // Assist friend
                LogFile->write(EQEMuLog::Debug, "Check aggro for %d assisting %d, target %d.", sender, mob, mobTarget);
                LogFile->write(EQEMuLog::Debug, "Check aggro for %s assisting %s, target %s.", sender->GetName(), mob->GetName(), mobTarget->GetName());
                                return mobTarget;
                }

Hope this helps a bit. I'm still investigating a fix, but that's likely the cause.

Regards,

krich