Jump to content

[9606] Causes client freezes


Alex

Recommended Posts

I had it reverted and working just before I've opened this thread :) If you revert [9606], most people will stop crying "ARGH! CLIENT FREEZE! WHAT THE FUCK?", and those who know may peacefully look for the solution using bug report.

---

According to the reports, client does not expect having GUID every time there. There must be cases when it is zero. Note: this mostly affect aura triggered spells. May be aura triggered spells must have zero as a caster GUID?

It's not arcane blast. It's this 'missile barrage available' effect causing hang. Something is amiss here.

I did the same thing and my players are happy now.

Link to comment
Share on other sites

Sorry for my bad english :)

Find one more freez(and client crash) with error 132.

It happens then player has weared items with 3 gems like this - http://www.wowhead.com/?item=42143 and try to wear item with 4 gem.

Your patches don't help =/ rev 9612

I hope you understand me :D

Wow.exe:

This application has encountered a critical error:

ERROR #132 (0x85100084) Fatal Exception
Program:    D:\\FTP\\Games\\WoW\\Wow.exe
Exception:    0xC0000005 (ACCESS_VIOLATION) at 001B:0067A295

The instruction at "0x0067A295" referenced memory at "0x00000004".
The memory could not be "read".

Link to comment
Share on other sites

Nah, it's still reproducible even after [9619]. So that's not just bytebuffer/flag problem. Client does not expect this GUID everytime in the first place, or expect something other.

2 Anti: just revert [9606] before build, and you'll be fine.

May I ask: what was the reason behind adding this GUID? Is it even needed? I could not find any visual differences with and without [9606].

Link to comment
Share on other sites

Nah, it's still reproducible even after [9619]. So that's not just bytebuffer/flag problem. Client does not expect this GUID everytime in the first place, or expect something other.
After thorough investigations in the client code, it definitely expects a packed GUID here, nothing else.

May I ask: what was the reason behind adding this GUID? Is it even needed? I could not find any visual differences with and without [9606].

For properly showing caster/target names for DoTs for example.

Theoretically speaking, the GUID isn't 'needed' - but then again, a lot of stuff isn't :). But to be blizzlike (and to fix what I just mentioned), we have to include it.

My bet is that something is going wrong elsewhere - though I don't know where.

Link to comment
Share on other sites

Forusim this freeze does not conclusively ALWAYS happen, but on a high pop server this happens every ~2 secs, and when it does happen, the whole set gets the freeze.... (usually like 20 players at a time)

This problem is still confirmed in the latest build.

I have been using the fix released on this thread and it has helped a great deal!

Link to comment
Share on other sites

Forusim this freeze does not conclusively ALWAYS happen, but on a high pop server this happens every ~2 secs, and when it does happen, the whole set gets the freeze.... (usually like 20 players at a time)

This problem is still confirmed in the latest build.

As said, I'm pretty sure these freezes originate from elsewhere...
Link to comment
Share on other sites

As said, I'm pretty sure these freezes originate from elsewhere...

It may be that wrong/unexpected data is reported in that field. Client expects packed GUID but it does not mean client expects the one sent by us currently. Everyone receiving the crappy update (those who are in the visibility range) get client freeze when this happens.

P.S. Confirmed after [9626] even with GCC 4.3 and -O1.

Reverting [9606] helps. I could not investigate this any further though, sorry.

Link to comment
Share on other sites

Hi, i have reverted the [ 9606 ] as Alex said and im with that "crash" now and is not very offen.

Core was generated by `./mangos-worldd -c ../etc/mangosd.conf'.
Program terminated with signal 11, Segmentation fault.
[New process 5404]
[New process 5406]
[New process 5405]
[New process 5403]
[New process 5402]
[New process 5349]
[New process 5347]
[New process 5345]
[New process 5343]
#0  FreezeDetectorRunnable::run (this=0x2aaab7eb2ae0)
   at ../../../src/mangosd/Master.cpp:104
104                    *((uint32 volatile*)NULL) = 0;                       // bang crash
#0  FreezeDetectorRunnable::run (this=0x2aaab7eb2ae0)
   at ../../../src/mangosd/Master.cpp:104
   curtime = <value optimized out>
#1  0x000000000088d515 in ACE_Based::Thread::ThreadTask (param=0x355eb51860)
   at ../../../src/shared/Threading.cpp:187
   _task = (class ACE_Based::Runnable *) 0x2aaab7eb2ae0
#2  0x000000355f406617 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3  0x000000355e8d3c2d in clone () from /lib64/libc.so.6
No symbol table info available.

Mangos Revision 9652

YTDB 541

Sd2 1660

I dont now if that is the crash that you are talking about but is just a info of someone that have made the revert.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use