Jump to content

Recommended Posts

Posted

Before I update can anyone confirm rev. 9616 fixed all of them or any of them?

My test server is down and so can't test it my self right now.

thank you!

Posted
9616 is just the same code as Zor proposed as a fix few posts above. Me and few other people gave feedback. Just read it ~~

Ok thank you. Did not see it was the fix from here lol :)

Posted
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.

Posted

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".

Posted

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].

Posted
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.

Posted

Just tested 9624 using Arcane Blast and Grounding Totem and had no freeze.

Alex are you sure you had the right version?

Tell us, what you did before you got freezes.

Posted

Exactly told in the 1st post, it gives 100% hang on test.

Maybe it's because I am compiling with GCC 4.4 and -O2, but reverting [9606] fixes these hangs. Will check with GCC 4.3 and -O1 soon.

Posted

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!

Posted
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...
Posted
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.

Posted

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.

Posted

Means you gotta do "thread apply all bt full" since it's a different thread that is freezing.

Also, this thread is about _client_ freezes, so better create a new thread about your issue.

×
×
  • 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