Bug 6335 - Transitional syntax variable declaration corrupts memory somehow
Transitional syntax variable declaration corrupts memory somehow
Status: RESOLVED FIXED
Product: SourceMod
Classification: Unclassified
Component: Transitional API
master
All All
: P5 enhancement
Assigned To: SourceMod Bugs
:
Depends on:
Blocks: 6317
  Show dependency treegraph
 
Reported: 2015-03-27 20:43 PDT by RedSword
Modified: 2015-04-01 01:18 PDT (History)
4 users (show)

See Also:


Attachments
Type sm_checkvardec to see the bug in action ; it will do a loop to add to an array in a subfunction (1.74 KB, text/plain)
2015-03-27 21:22 PDT, RedSword
no flags Details
sm_checkvardec2 simple assignment (1.04 KB, text/plain)
2015-03-27 22:07 PDT, RedSword
no flags Details

Description RedSword 2015-03-27 20:43:17 PDT
As I was trying to find the source of the bug 6317 I found that the following line (L392) in fire.sp causes problem :

int target_list[MAXPLAYERS], target_count;

Even though if I print the content of those values, everything will be fine and zeroed, using sm_burn (L392 is under Command_Burn which handles sm_burn), a strange behaviour occurs when using ProcessTargetString, as said in bug 6317 : The first client (clientId=1) will not be targetable using for instance "sm_burn @all", but he will be targeted for single-target found via ProcessTargetString (i.e. "sm_burn @me" will trigger burn on clientId=1; even though I'm not clientId 1).

The code is very similar, in 1.6 syntax (i.e. found with sm_freeze, which works fine). If I split the variable declaration on L392 in two lines :

int target_list[MAXPLAYERS];
int target_count;

The problem disappears (of course recompile).

I do not know how to do a simpler case, as it seems a sub-function is needed.

It feels like the problem comes from some wrong memory addressing (stack frame arithmetic I'd guess).
Comment 1 RedSword 2015-03-27 20:51:14 PDT
Enforcing "#pragma newdecls required", just before Command_Burn, and modifying it accordingly doesn't help.
Comment 2 RedSword 2015-03-27 21:22:56 PDT
Created attachment 3979 [details]
Type sm_checkvardec to see the bug in action ; it will do a loop to add to an array in a subfunction

Just type sm_checkvardec with this plugin to see the bug "in action".
Comment 3 RedSword 2015-03-27 21:26:55 PDT
sm_checkvardec

Will output :

testArray[0] = 3
testArray[1] = 2
testArray[2] = 3

While it should be 0, 1, 2, 3. The array count will be worth 3 (while it should be worth 4; It is the same as doing "sm_checkvardec 0 4")

And doing "sm_checkvardec 3 -1" (from 3 to 0 included) :

testArray[0] = 6
testArray[1] = 0
testArray[2] = 0
testArray[3] = 2
testArray[4] = 1
testArray[5] = 0

While it should be 3, 2, 1, 0. The array count will also be worth 6 (should be 4).
Comment 4 RedSword 2015-03-27 22:07:38 PDT
Created attachment 3980 [details]
sm_checkvardec2 simple assignment

Doing "sm_checkvardec2" will print :

testArray[0] = 666;
testArray[1] = 0;
testArray[2] = 0;
testArray[3] = 0;
testArray[4] = 0;
aVarInt value = 666, aVarInt2 value = 666

while it should print :

testArray[0] = 0;
testArray[1] = 0;
testArray[2] = 0;
testArray[3] = 0;
testArray[4] = 0;
aVarInt value = 1337, aVarInt2 value = 666

note that if I remove aVarInt2 fully from the program (as well as 666), testArray[0] = 1337 instead.
Comment 5 David Anderson [:dvander] 2015-03-30 14:31:33 PDT
RedSword, can you see if the latest snapshot fixes this problem? I think it was a bug in the compiler that Peace-Maker found, so you'll have to recompile the plugin.
Comment 6 Peace-Maker 2015-03-30 16:28:13 PDT
Try spcomp from the latest 1.8 snapshot.
Comment 7 RedSword 2015-04-01 00:57:47 PDT
Should be solved. Both above commands generate sound outputs. sm_burn @me burns me fine.
Comment 8 RedSword 2015-04-01 01:18:17 PDT
Related to https://github.com/alliedmodders/sourcepawn/commit/f75ca63a9f0c594442a83144f5cca48ae055f453 for curious people.

Note You need to log in before you can comment on or make changes to this bug.