Dron01

Ofc we should recheck it...

Sad but true.

Holder created : 0x72646640

Holder deleted : 0x72646640

...

Unit::GetAura:

(i*)->m_spellAuraHolder : 0x72646640

And shine Aurora now. Specific bug with persistent auras, I guess...

Looking for a solution, hmm ... We should move insertion in m_modAuras to aura constructor and deletion from it to aura destructor.

It will break original idea partially but this will do the trick, I think.

Another way is to look through code to find why persistent aura holders get deleted before its components. There's nothing else to loose, maybe we should add ASSERT on aura deletion to the holder destructor?

Then we can see the stacktrace at least...

SpellAuraHolder::~SpellAuraHolder()
{
   // note: auras in delete list won't be affected since they clear themselves from holder when adding to deletedAuraslist
   for (int32 i = 0; i < MAX_EFFECT_INDEX; ++i)
       if (Aura *aur = m_auras[i])
           delete aur;
}

can it be that somewhy holder deletes itself and its auras without clearing itself out from arrays?

He-he, of course it was right. I thought GetAurasByType forms something like array of pointers to those auras and then returns a pointer to its beginning, didn't thought it could be static array. So aura should be deleted from m_modAuras[type] (which is just a list of pointers with complicated name ) and it does NOT. But aura itself is deleted and deallocated really so the pointer stored in this list becomes invalid. Anyway, we are close...

So it's not needed

Zergtmn, what did you mean? Does reference automatically remove pointers to its elements when they are deleted? Anyway, this code worked since some "4-digits" revisions, and I'm in doubts...

+    for (Unit::AuraList::const_iterator iter = target->GetAurasByType(SPELL_AURA_MOD_DECREASE_SPEED).begin(); iter != target->GetAurasByType(SPELL_AURA_MOD_DECREASE_SPEED).end()

Isn't it too slow?.. Every loop execution it gets an array of auras and then checks it, even if aura is not deleted!

Unit::AuraList &slowingAuras = (Unit::AuraList&)(target->GetAurasByType(SPELL_AURA_MOD_DECREASE_SPEED))

Is this safe? If yes, we could delete elements right in the loop...

slowingAuras is a constant adress list. Aura is deleted and iter returns to beginning of the slowingAuras. Of course, now this list contains an address of a deleted aura element, thus code is unable to retrieve a SpellInfo...

We need to refresh this list somehow before using it again.

That's what I think.

Seems that persistent area aura related code is not working properly. _AddAura() and _RemoveAura() functions in Aura class are also redundant.

Small bug.

Impact proc talent auras get dispelled from caster after use of IceBlock. They are considered negative, as I think.

if(spellproto->AttributesEx & SPELL_ATTR_EX_NEGATIVE) // <----- here at IsPositiveEffect(...) (spell 12358)

I have situation that semms strange to me.

I'm using FreeBSD 8.0-RELEASE (x64), here is the "top" command output:

CPU:  5.4% user,  0.0% nice,  2.1% system,  0.4% interrupt, 92.2% idle
Mem: 4565M Active, 2299M Inact, 657M Wired, 117M Cache, 824M Buf, 259M Free
Swap: 4096M Total, 1563M Used, 2533M Free, 38% Inuse

 PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
24075 wow        10  44    0  6638M  3911M select  1 642:50 13.77% mangos-world

Can someone plz explain me what is "Inactive" memory and why isn't it cleared and freed in cases when players logout/grids unload?

I also used cactus system to view it graphically and as I can see the memory usage of process is only increasing, but in fact it includes less memory ("RES" field).

So I wonder how can I clear all inactive memory (that in fact is needed only for quicker access to recent data) and make it free...

What does prevent us from using handler for TG at Player::_ApplyWeaponDependentAuraMods?

Mmm I am not very good at English but I will try to explain what is in my mind.

First I saw the Player::UninviteFromGroup() function which includes these lines:

    if(group->GetMembersCount() <= 1)                       // group has just 1 member => disband
   {
       if(group->IsCreated())
       {
           group->Disband(true);
           sObjectMgr.RemoveGroup(group);
       }
       else
           group->RemoveAllInvites();

       delete group;
   }

See? First, group is getting disbanded and then the destructor of Group class is called and memory is freeing. There's a similar code at all disband group cases.

But look at an another small issue

In function Group:: Disband(bool hideDestroy) there's an unneeded line:

    RollId.clear();

which, afaik, completely clears the pointer list of all existing rolls.

But in destructor, ~Group(), I saw the right way of deletion:

Rolls::iterator itr;
   while(!RollId.empty())
   {
       itr = RollId.begin();
       Roll *r = *itr;
       RollId.erase(itr);
       delete(r);
   }

And so, if group is getting disbanded this way and has existing rolls, they will not be deleted at group destructor because the pointer list is already clear...

Am I right?

Confirmed.

No crash dumps available, it just freezes when memory usage reaches its ceiling...

Derex has pointed out that there was an issue with more than 1024 connected players. It has been fixed in MaNGOS_soap_patch_2010_02_23_00_31_55.diff, huge thanks for that

Should I recompile ACE to make this fix work? Or does it affect only server?

All you should do is to add some packet handlers. They work perfect for me.

But be ready to fix

1) PET_FOLLOW_ANGLE

2) target map of spell "Initialize Images"

3) aim losing for enemy attackers of the mage

4) caster spell "Clone Me"

sorry, it does.

at Unit::SpellDamageBonus:

case SPELLFAMILY_WARLOCK:
       {
           // Drain Soul
           if (spellProto->SpellFamilyFlags & UI64LIT(0x0000000000004000))
           {
               if (pVictim->GetHealth() * 100 / pVictim->GetMaxHealth() <= 25)
                 DoneTotalMod *= 4;
           }

+            //conflagrate coef
+            if (spellProto->TargetAuraState == AURA_STATE_CONFLAGRATE)
+                return pdamage;

           break;
       }