Hm. Wonder if it's a serialization issue, then. Total number of characters in character names going over a certain accidental limit based on buffer size?
|
I have no idea Shendare, this surpasses my knowledge of C++. Some things I can do and figure out but when you get into the streaming of data from client to server, that is past me. I will get there one day and this has been a great learning experience.
I will not post the magic combination here, but give it to the power that be. EDIT: Just to be sure it is not my server that has something screwed up, I did it on PEQTGC and it crashed, 5 characters with the same combination. It boils down to the total character length of the characters names being a certain number. |
Drajor and Uleat I sent both of you a packet dump
|
I just committed a change that may address this issue.
Give it a shot and see it that helps. EDIT: That will clean up my coding..if there's still an issue, it should be a little easier to trace. |
Roger that. Probably will be Saturday before I can test it, but I definitely will. Thanks for looking into it, also excited to see what the change was.
|
Since the buffer was an allocation and not an initialization, it would be possible to have the character at eq_cse.Name[<strlen> + 1]
not be 0... And since I was taking name strlen from the eq buffer and not emu buffer, it could have thrown off the length of the entry. If you still have issues, let me know and I'll look at the server generation code. |
One of my servers is working off January source, and until I can move some of my custom things over, I am going to have to keep using that source. These are the lines I will have to change if I am thinking right.
Code:
bufptr += strlen(emu->name[r]); Code:
eq_cse->Name[0] = '\0'; Code:
ENCODE(OP_SendCharInfo) |
Compiling now, I will report back.
Yeah, still crashing before character select. |
I pushed a memset as well in the charsel-gen code..but, that likely won't help your case.
Let me look over what you have in this encode. I'm assuming that you're still using the Ti-based character select struct? (pre-variable toons per client version) EDIT: Your Code:
memcpy(eq2->name, emu->name[r], strlen(emu->name[r]) + 1); Still looking over it..I'm not seeing an immediate problem..but, might need to compare the structs to make sure something isn't off there. EDIT2: Does your UF::structs::CharacterSelectEntry_Struct have its name field declared as char name[1] or char name[0]? EDIT3: Ok, just did a diff of crash/no crash hex dumps after adding in the 'ppy' to the crash one - there was no difference. The packet structure appears to be properly filled in the crash version and I'm just not seeing anything in the encode function that would cause this. Have you tried running it without the scope declarations? I'm wondering if the wrong struct isn't being referenced for size... |
Uleat are you getting your client to crash on your end? I am just wondering if you are able to replicate the problem yourself?
|
Nothing here..hence my somewhat random approach.
I'm just going over potholes in the server code and reviewing what you posted above. |
It always does it for me using UF when the character name count with all characters in the account hits 38. Tried it on two servers with the same result, one being PEQTGC.
|
Ahh, kk..last I tried was 7-char names. I'll take a look at the 38 count.
EDIT: I did one better..I created an account and used all of your names... Yes, it crashed..so, it is definitely reproduceable in the base code. |
[Sun May 24 22:25:07 2015]01870:fatal error in main thread Code = c0000005 ADDR=0x2e4080c0
Buffer overrun... |
How did you get a buffer overrun? Where did that present itself?
|
All times are GMT -4. The time now is 05:34 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.