Scrolling through weapons too fast causes a freeze

[Marisa the Magician]

This is in git builds. I've found it specifically in e4e86dd4f (and still happens in current master as of posting this) but it could go back more commits. (Investigating this right now)

Only happens when cycling, not with the number keys. One consistent way to reproduce the freeze is to rapidly scroll down then up (happens even if you just have pistol and fist). The freeze only happens with asmjit.

A quick look with gdb shows that it's somehow stuck doing calls to FindInventory (can't see what the JIT'd side is doing).

[_mental_]

I managed to reproduce it once occasionally. It's hard to investigate such things on POSIX because of crippled callstack. It looks like an infinite loop but that's all I can tell about it at the moment.

[gramps]

I wonder, is it possible to reproduce that using something other than the mouse wheel to cycle weapons?

There's something inherently weird about mouse wheels; if you scroll them fast enough you can get bogus input on some platforms, usually mouse button presses for button 6 or 7 or something that likely doesn't physically exist on the mouse. I've noticed this in everything from SDL to console applications. At first I thought it was something weird with my system, but have seen this in bug reports too. No idea what causes it, or if it's relevant here, but have had to work around it in the past by throwing out any high-number button presses.

[_mental_]

Infinite loop itself is caused by this line. The real problem, however, lies somewhere deeper.

Here is a cleaner artificial sample

Code: Select all

class Test : Actor
{
	int, int Func1()
	{
		return 42, 31337;
	}
	
	int, int Func2()
	{
		return Func1();      <-- here is the problem
	}
	
	override void BeginPlay()
	{
		int a, b;
		[a, b] = Func2();
		
		string ca = 42 == a ? Font.TEXTCOLOR_GREEN : Font.TEXTCOLOR_RED;
		string cb = 31337 == b ? Font.TEXTCOLOR_GREEN : Font.TEXTCOLOR_RED;
		console.printf("%s42 == %i\n%s31337 == %i", ca, a, cb, b);
	}
}

With JIT or without assertions enabled it will output the following upon summoning Test actor

Code: Select all

42 == 42
31337 == 0

Otherwise, it will stop on this assertion due to only one value returned from Test.Func1().

Rewriting Test.Func2() as the following solves the problem

Code: Select all

	int, int Func2()
	{
		int a, b;
		[a, b] = Func1();
		return a, b;
	}

Apparently, returning via a direct function call with multiple results is screwed at the moment.

[Graf Zahl]

VM code for the outer return is not correct. Apparently the VM itself picks up on the inner OP_RESULTs somehow. The direct native call requires proper setup and cannot propagate this info.
Ultimately this is a direct result of the messy calling convention the VM uses.

I absolutely don't get it why this was written with asserts as the only means to catch errors. Another part where this was initially done was the register allocator. One it ran out of space it started going totally haywire in release builds with meaningless crashes and so on because it had no sanity checks except for a single assert. Fortunately I found that one before it could do some real damage to production code.