Deadlock when calling RTDPerkList.Get()

[naydef]

Bug description

L 04/01/2024 - 17:02:08: [SM] Exception reported: Not enough space on the stack
L 04/01/2024 - 17:02:08: [SM] Blaming: chaos_machine.smx
L 04/01/2024 - 17:02:08: [SM] Call stack trace:
L 04/01/2024 - 17:02:08: [SM] [1] Line 744, C:\TF2SERVER\steamapps\common\Team Fortress 2 Dedicated Server\tf\addons\sourcemod\scripting\NEC\chaos_machine.sp::RTDPerkList.Get
L 04/01/2024 - 17:03:39: [SM] [33] Line 587, rtd2::RTDPerkList.Get
L 04/01/2024 - 17:03:39: [SM] [34] Line 587, rtd2::RTDPerkList.Get
L 04/01/2024 - 17:03:39: [SM] [35] Line 587, rtd2::RTDPerkList.Get
L 04/01/2024 - 17:03:39: [SM] [36] Line 587, rtd2::RTDPerkList.Get
L 04/01/2024 - 17:03:39: [SM] [37] Line 587, rtd2::RTDPerkList.Get
L 04/01/2024 - 17:03:39: [SM] [38] Line 587, rtd2::RTDPerkList.Get
L 04/01/2024 - 17:03:39: [SM] [39] Line 587, rtd2::RTDPerkList.Get
...

Report checks

The stack trace below is of older version of the plugin, but I guess the issue still occurs depending on circumstances. We're using SM 1.11 some build. It seems the compiler has different behavior depending on version. Basically the methodmap RTDPerkList has a method called Get(), while at the same time deriving from ArrayList which also has a method called Get(). For some reason when the method tries to call ArrayList.Get(), it instead calls RTDPerkList.Get thus resulting in a deadlock.

I can guess the same issue will occur if we use latest RTD plugin with this SM compiler, so I guess the code should be more explicit when calling the Get method:

public RTDPerk Get(int i){
-		return view_as<RTDPerk>(this.Get(i));
+		return view_as<RTDPerk>(view_as<ArrayList>(this).Get(i));
	}

Required

• The bug does not have an open issue.
• I have described the bug.
• I mentioned whether the bug is sporadic or systematic.

[Phil25]

Thanks for letting me know, this issue has been fixed inside the plugin some time ago, but I forgot the part about the include file. I'll get on it soon-ish (this week?).

In the meantime, since it's a header file, correcting that line yourself should work fine.

[Phil25]

Fixed in 2.5.5.