Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=684
(originally mentioned in
bugreport #641)
When doing certain types of variable assignment, a very unsafe situation can occur. It is illustrated by the following script:
CODE
geffen,116,66,4 script Proof of concept 113,{
set @str1$, "poring poporing";
set @str2$, @str1$;
close;
}
If you breakpoint pc_setregstr(), you'll see that in the first step, the string literal is copied over to sd->regstr[0].str. Then in the second step, this will be the state of relevant variables:
CODE
str 0x05123974 "poring poporing" char *
sd->regstr[0].data 0x05123974 "poring poporing" char [256]
As you can see, the new string to be written has the same memory address as the storage space around where the string is supposed to be written.
So, when this code executes
CODE
sd->regstr_num++;
RECREATE(sd->regstr, struct script_regstr, sd->regstr_num);
strcpy(sd->regstr[i].data, str);
the 'realloc' in the second row will under certain conditions cause the entire destination block to move. This will make 'str' point to memory that is no longer valid, and make the code save a string var's value to some random junk.
The reason why this hasn't caused a mess up 'till now is, that if you use the ea memory manager, it doesn't destroy deallocated memory - meaning the data is still there intact. Also, if you use a 'release' library, chances are that the memory allocation routines are 'optimized' to not waste time destroying deallocated data.
PS: this bug might also affect other variable types who use this same data saving pattern.
PS: same defect present in available jAthena script engine.
This post has been edited by theultramage: Dec 24 2007, 05:15 AM