Got this bug
Got this trouble with UF MQ2
Is there any solution for this ?? Many thanks.
Mon May 19, 2014 8:03 pm
Probably :)
A stack trace would be more helpful so we could see whats upstream from that. What were you doing at the time? Can you easily recreate the bug?
A stack trace would be more helpful so we could see whats upstream from that. What were you doing at the time? Can you easily recreate the bug?
Tue May 20, 2014 6:54 am
Project Lead
Hi Maudigan , yes always jump this bug on my wizard everytime when i do /macro xxxx
Thu May 22, 2014 6:29 am
Are you on a custom server that patches EQ; I'm guessing custom spells?
Thu May 22, 2014 6:56 am
Project Lead
im on PEQ in lan , and you don't remember me hahahahahaha im the spaniard ;-)
Is there any solution for me ??
Is there any solution for me ??
Thu May 22, 2014 6:59 am
I've seen that before and I think we narrowed it down to a bad spell file on a custom server. I think it was on a wizard too if I remember right. I'm thinking it might be something bugged out in your spell book, a slot somehow assigned to a spell that doesn't exist... I need to get in there and look at the code again to refresh my memory on what it's doing and see if I can come up with a way to test it. If I don't get back with you this weekend feel free to remind me.
Edit: and I remember you :)
Edit: and I remember you :)
Fri May 23, 2014 6:59 am
Project Lead
c++
That's the relevant function. I'm a bit rusty and I don't have the assembly in front of me--if you know how to pull the relevant assembly from your debugger and post it that would be awesome.
This is a guess, but its probably using the _fastcall convention which passes the parameter, the spell ID in this case, using the ECX register. The ECX register, assuming its still holding the spell ID at the time of the crash, is set to 787Eh, or this spell: http://mqemulator.net/spell.php?id=30846 which is a wizard spell.
I don't know why your macro would be using that spell though, it makes me think I'm misinterpreting it.
Does your macro us that spell? If it does, can you try to cast the spell without using the macro, preferable in whatever way the macro does it, like /casting 30846 or something like that. Maybe you could post the macro, or PM it to me if its private.
Fri May 23, 2014 6:17 pm
Project Lead
I feel like I should warn you that I don't usually use debuggers :)
I usually diagnose by adding output lines to my code. If it were me, id just change the routine to the following code and then recreate the crash to see what spell id is crashing it. A try/catch block with some WriteChatf output would work too. Once we have the spell id we can work from there.
The only time I mess with assembly is in IDA pro so I'm a little out of my element.
I usually diagnose by adding output lines to my code. If it were me, id just change the routine to the following code and then recreate the crash to see what spell id is crashing it. A try/catch block with some WriteChatf output would work too. Once we have the spell id we can work from there.
c++
The only time I mess with assembly is in IDA pro so I'm a little out of my element.
Last edited by Maudigan on Sun May 25, 2014 4:39 pm; edited 1 time in total
Fri May 23, 2014 7:06 pm
Project Lead
Omg !! hahahaha useless of me hahaha , i will try that debugspellalways line , seems that could work and not make crash de macro , but i will test it tomorrow , im out this weekend out from home . i will explain if all run ok or still at the same crash with that new lines.
Sun May 25, 2014 12:20 pm
I've been thinking about this, and it just didn't make sense.... the code looks good. I was thinking a null pointer exception, but the code doesn't look bad. I think it might be an indexing problem on the spell array.
The spells_us.txt files last entry is this:
and in EQData.h there is the following
So the SpellMgr has a collection, Spells, with 6D60h (28000) elements. So the last index would be 27999, which matches the last spell in your clients spell file.
Now, assuming my _fastcall guess is correct, then the index being used on that array is 30846... which doesn't exist. It's an array of pointers, so it just a run together list of 4 byte segments, each one containing a pointer to a spell. 30846 doesn't exist, so what would happen is, it would read past that list of pointers, 11388 bytes past the end. (30846 - 27999 multiplied by 4 bytes is 11388 bytes)
It grabs whatever 4 bytes happens to be at that memory location, and tries to treat it as if it's a pointer to a spell. Whatever those 4 bytes are, they aren't NULL, but they aren't a pointer either. So it gets past all those NULL checks, but crashes when it tries to treat it as an address.
Why might it be feeding it that weird ID? PEQ's database has spells in it that are in the live client, but don't exist in the old clients. When I look in the PEQ database, the highest ID spell is, 32999.
I don't know what exactly your macro is doing that is causing it to try and access information about that particular spell but that's all I can figure. That may be totally wrong... but it's my best guess right now. And it's pretty suspicious that the thing that most seems like it's the index is bigger than the alocated space for that pointer array.
To test it, just add an index check, something like the following. I don't think increasing the constant to make the array bigger would work since it's pointing to an existing structure in the client, unless you added a modern spell file. The array is kind of just getting used as a data type to instruct MacroQuest how to interact with an existing structure within eqgame.exe.
The spells_us.txt files last entry is this:
and in EQData.h there is the following
c++
So the SpellMgr has a collection, Spells, with 6D60h (28000) elements. So the last index would be 27999, which matches the last spell in your clients spell file.
Now, assuming my _fastcall guess is correct, then the index being used on that array is 30846... which doesn't exist. It's an array of pointers, so it just a run together list of 4 byte segments, each one containing a pointer to a spell. 30846 doesn't exist, so what would happen is, it would read past that list of pointers, 11388 bytes past the end. (30846 - 27999 multiplied by 4 bytes is 11388 bytes)
It grabs whatever 4 bytes happens to be at that memory location, and tries to treat it as if it's a pointer to a spell. Whatever those 4 bytes are, they aren't NULL, but they aren't a pointer either. So it gets past all those NULL checks, but crashes when it tries to treat it as an address.
Why might it be feeding it that weird ID? PEQ's database has spells in it that are in the live client, but don't exist in the old clients. When I look in the PEQ database, the highest ID spell is, 32999.
I don't know what exactly your macro is doing that is causing it to try and access information about that particular spell but that's all I can figure. That may be totally wrong... but it's my best guess right now. And it's pretty suspicious that the thing that most seems like it's the index is bigger than the alocated space for that pointer array.
To test it, just add an index check, something like the following. I don't think increasing the constant to make the array bigger would work since it's pointing to an existing structure in the client, unless you added a modern spell file. The array is kind of just getting used as a data type to instruct MacroQuest how to interact with an existing structure within eqgame.exe.
c++
Last edited by Maudigan on Mon May 26, 2014 11:27 am; edited 1 time in total
Sun May 25, 2014 3:48 pm
Project Lead
WoW !!! i test this solution you put :
And for the moment works and not crash , my congratulations for you , today i was start the morning doing some things with the code with the debug lines etc and any work , but you give me a lesson and works hahahaha
YOU ARE THE BEST ONE Maudi !!! Mny thanks friend and now all peeps who gots this bug too got a great solution in the wizards crash.
And i miss one thing this crash appears to me in every macro i write or test , modbot , raiddruid , afknuke ..... the list of macros made by me or downloaded from others was so long , but you did it. MY CONGRATULATIONS FOR YOU AGAIN !!!
Be safe friend you are rocks !!!
c++
And for the moment works and not crash , my congratulations for you , today i was start the morning doing some things with the code with the debug lines etc and any work , but you give me a lesson and works hahahaha
YOU ARE THE BEST ONE Maudi !!! Mny thanks friend and now all peeps who gots this bug too got a great solution in the wizards crash.
And i miss one thing this crash appears to me in every macro i write or test , modbot , raiddruid , afknuke ..... the list of macros made by me or downloaded from others was so long , but you did it. MY CONGRATULATIONS FOR YOU AGAIN !!!
Be safe friend you are rocks !!!
Mon May 26, 2014 10:30 am