+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2)
+--- Thread: Recursion limit? (/showthread.php?tid=2504)
Recursion limit? - TerryRitchie - 03-12-2024
Is there a limit to the number of recursions that QB64PE can handle? The code below works well with a circle the radius of 50, but increase the radius to 100 and the program will crash part way through.
Also, I figured out why the IDE was using so much RAM (256MB as I reported in another thread). Every crash of this program increases the IDE RAM usage.
Keep in mind the code below is just me playing around. It's not optimized at all or debugged in any way. Just me experimenting.
Code: (Select All)
OPTION _EXPLICIT
DIM Image AS LONG
DIM x AS INTEGER
DIM y AS INTEGER
Image = _NEWIMAGE(800, 600, 32)
SCREEN Image
MemCLS Image, _RGB32(255, 255, 255)
CIRCLE (399, 299), 50, _RGB32(0, 0, 0) ' recursion works at radius 50, fails at radius 100
FloodPaint 399, 299, _RGB32(255, 0, 255), _RGB32(0, 0, 0) ' recursive paint
SUB FloodPaint (x AS INTEGER, y AS INTEGER, c AS _UNSIGNED LONG, b AS _UNSIGNED LONG)
' x,y - paint location
' c - paint color
' b - border color
DIM p AS _UNSIGNED LONG ' pixel color
STATIC Iterations AS LONG ' the number of iterations
IF x = -1 OR y = -1 OR x = _WIDTH(_DEST) OR y = _HEIGHT(_DEST) THEN EXIT SUB
p = POINT(x, y)
IF p = b OR p = c THEN EXIT SUB
PSET (x, y), c
Iterations = Iterations + 1
' Just some code to show what's going on and slow things down a bit
LOCATE 1, 1
PRINT x, y, Iterations
_DELAY .001
' Check neighboring pixels
FloodPaint x - 1, y, c, b
FloodPaint x + 1, y, c, b
FloodPaint x, y - 1, c, b
FloodPaint x, y + 1, c, b
Iterations = Iterations - 1
END SUB
FUNCTION xyOFFSET%& (i AS LONG, x AS INTEGER, y AS INTEGER)
' Calculates the pixel memory address offset location within an image given the x,y coordinate pair
'
' i - image handle
' x,y - pixel coordinate
$CHECKING:OFF
IF (i = 0 OR i < -1) AND _PIXELSIZE(i) = 4 THEN ' valid 32bit image?
xyOFFSET%& = y * _WIDTH(i) * 4 + x * 4 ' yes, calculate pixel offset location
END IF
$CHECKING:ON
END FUNCTION
SUB MemCLS (i AS LONG, c AS _UNSIGNED LONG)
' Clears an image with provided color
'
' i - image handle
' c - 32bit color
DIM m AS _MEM
$CHECKING:OFF
IF (i = 0 OR i < -1) AND _PIXELSIZE(i) = 4 THEN ' valid 32bit image?
m = _MEMIMAGE(i)
_MEMFILL m, m.OFFSET, m.SIZE, c
_MEMFREE m
$CHECKING:ON
END IF
END SUBRE: Recursion limit? - SMcNeill - 03-12-2024
Recursion limits are set by the gcc compiler itself, and I don't know what they default to.
You can change the setting manually, by going into options, Compiler Settings, and editing that line for C++ Linker. Add something similar to:
--stack,4194304
The above should increase the stack to 4MB in size, which from my testing is enough to run 100 recursions without any issues on my PC.
>>Every crash of this program increases the IDE RAM usage.
As for this, I just can't see how that's possible. The programs aren't linked. Your source code is compiled and then we simply shell out to that compiled version and run it -- it has no impact on the IDE whatsoever.
Any chance that you have a stray $DEBUG statement going on there somewhere? That might could explain the issue, as debug DOES link the two programs together via TCP/IP so you can watch the variable values and such as the program is running.
RE: Recursion limit? - TerryRitchie - 03-12-2024
(03-12-2024, 03:56 AM)SMcNeill Wrote: Recursion limits are set by the gcc compiler itself, and I don't know what they default to.Nope, no $DEBUG in use.
You can change the setting manually, by going into options, Compiler Settings, and editing that line for C++ Linker. Add something similar to:
--stack,4194304
The above should increase the stack to 4MB in size, which from my testing is enough to run 100 recursions without any issues on my PC.
>>Every crash of this program increases the IDE RAM usage.
As for this, I just can't see how that's possible. The programs aren't linked. Your source code is compiled and then we simply shell out to that compiled version and run it -- it has no impact on the IDE whatsoever.
Any chance that you have a stray $DEBUG statement going on there somewhere? That might could explain the issue, as debug DOES link the two programs together via TCP/IP so you can watch the variable values and such as the program is running.
I narrowed down the flickering too. It only happens when I press the left or right SHIFT, CTRL, or ALT keys. The IDE line numbers and current line highlighter flicker as I'm typing this every time a shift key is pressed. While this forum editor is active I can repeatedly press the shift key to make the IDE flicker at will. When I press either ALT key the IDE menu letters light up too. If I hold the ALT key the IDE menu stays lit up but the browser, and not the IDE, picks up the keystrokes, such as ALT-F.
It's as if for a very brief moment the IDE window is getting then losing focus. You should be able to recreate what I'm seeing by running the code I posted above and while it's running press the shift key repeatedly. If not then it must be something in my computer that doesn't like one of the updates.
I just opened v 3.11.0 and the flickering does not happen with any of the keys.
I do use two screens if that makes a difference.
I'll play around with the stack setting to see what I get as well, thanks for pointing that out.
Terry
RE: Recursion limit? - Jack - 03-12-2024
Terry
on windows to set the stack in compiler options the syntax is: -Wl,--stack, 4194304
in Ubuntu I had to use: -Wl,-z,stack-size= 4194304
RE: Recursion limit? - SMcNeill - 03-12-2024
Aye. Sorry. I must've not copied that whole line completely. Thanks for the correction, @Jack
(As for Linux, I'll admit to being clueless of the differences. I'm 100% a Windows user.)
RE: Recursion limit? - GareBear - 03-12-2024
TerryRitchie,
I use Slackware linux 15.0 with 3.12.0 QB64PE on an originally Windows 7 laptop. This is the limit I hit before it drops out:
Code: (Select All)
Circle (399, 299), 192, _RGB32(0, 0, 0) ' recursion works at radius 50, fails at radius 100with this line it ends normally.
At 193 I get 99.8% of the circle filled before stopping.