AppGameKit Classic Chat->[SOLVED] Crash with no error message: spaces(-1)
N
Nieb Joined: 13th May 2014
Location: Lurking
Posted: 22nd Jun 2022 23:56
If spaces(-1) is executed the app will crash. It just disappears, no error message box.
V
Virtual Nomad Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 23rd Jun 2022 1:29
confirmed. issue added to the repo: https://github.com/TheGameCreators/AGK-Studio/issues/996
D
Dark Raven Joined: 27th Jul 2014
Location: United States
Posted: 25th Jun 2022 4:48
I'm not sure about the crashing with error message but I believe it probably has something to do with the negative 1. On the help site if you set to show c++ version it is looking to pass a unsigned integer which mean there should be an error message because of the passing of a negative number. So the lack of error and crashing is a bug but the negative number is probably what is causing it. So I'm wondering if any other function that can't take a negative number will do the same thing.
N
Nieb Joined: 13th May 2014
Location: Lurking
Posted: 4th Jul 2022 15:13
After the update it now shows the new error message with spaces(0). This was fine before, it did not cause a crash.
V
Virtual Nomad Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 4th Jul 2022 16:04
yah, i'd say the bug is a little worse now.

i dont want an error on 0. we might have a variable that inserts spaces for formatting reasons and 0 should be valid.

seems like the attempted fix did:

+ Code Snippet
If Spaces() = 0 then Error()

vs
+ Code Snippet
If Spaces() < 0


ie, probably a simple typo which is why i want to see the fix in the first place.

ah, well. in the meantime:

+ Code Snippet
do
	For x = -1 to 1
		print(Space(x) + "Hello!")
	next x
	
	Print(ScreenFPS())
	Sync()
loop

Function Space(x)
	if x > 0 then Result$ = Spaces(x) else Result$ = ""
EndFunction Result$
Z
Zaxxan Joined: 17th Nov 2020
Location: England
Posted: 6th Jul 2022 15:16
Unfortunately this is unlikely to get fixed for another 3 months.
M
MadBit Joined: 25th Jun 2009
Location: Germany
Posted: 7th Jul 2022 12:19
From the github repository -
+ Code Snippet
//****f* Core/Strings/Spaces
// FUNCTION
//   Creates a string of spaces equal to the length passed in.
// INPUTS
//   length -- The length of the string of spaces to create
// SOURCE
char* agk::Spaces( UINT length )
//****
{
	if ( length <= 0 )
	{
#ifdef _AGK_ERROR_CHECK
		agk::Error ( "Negative valued passed into the Spaces command" );
#endif
		return 0;
	}

	char *str = new char[ length+1 ];
	UINT n = 0;
	for ( n=0; n<length; n++ ) str[n]=32;
	str[n]=0;
	return str;
}


The way the function is set up here, it should never stop at negative values.
Since the parameter length is defined as unsigned int (as Dark Raven has already noted), a -1 in hex notation would be equal to 0xffffffff (32 bit) and always positive.
Consequently, the termination condition is never reached.
Or do I see this wrong?
N
Nieb Joined: 13th May 2014
Location: Lurking
Posted: 7th Jul 2022 16:29
Good catch. I've noticed if you, mistakenly, put a print() in a long loop bad things happen, even if the loop only executes once.

Example:
+ Code Snippet
FOR i = 0 TO 100000
    Print("ABC 123 !?")
NEXT i
Sync()

DO
    Print(ScreenFPS())
    Sync()
LOOP

Here, my FPS will only be ~17 after running the long print loop only once. Also, windows reports using 600MB of RAM and high CPU usage.

So, perhaps the original issue wasn't "can't do negative spaces" but, instead "can't print a string with 4294967295 characters".
Maybe the print() function could use some safety checks on string-length and number-of-calls per-frame.

Only changing the spaces() code to: if ( length < 0 ) is still fine. If the most significant bit (or signed bit) is set it's a good indication something went wrong.
M
MadBit Joined: 25th Jun 2009
Location: Germany
Posted: 8th Jul 2022 6:45
aybe the print() function could use some safety checks on string-length and number-of-calls per-frame.


This is how it will have been.
Since +1 is added to the length when reserving memory, there is an integer overflow and possibly 0xffffff becomes 0x00000000 again.
Thus, 0 bytes would be reserved for the string.
If one then writes into it, there is of course a memory error.

The correct if statement would rather be the following.
+ Code Snippet
    if ( length &gt; 0x7fffffff )
    {
#ifdef _AGK_ERROR_CHECK
        agk::Error ( "Negative valued passed into the Spaces command" );
#endif
        return 0;
    }

But I also wonder if a string of more than 2 terrabytes should be allowed.
That is just my opinion.