Bugzilla – Bug 6335
Transitional syntax variable declaration corrupts memory somehow
Last modified: 2015-04-01 01:18: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).
Enforcing "#pragma newdecls required", just before Command_Burn, and modifying it accordingly doesn't help.
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".
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).
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.
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.
Try spcomp from the latest 1.8 snapshot.
Should be solved. Both above commands generate sound outputs. sm_burn @me burns me fine.
Related to https://github.com/alliedmodders/sourcepawn/commit/f75ca63a9f0c594442a83144f5cca48ae055f453 for curious people.