Recursion limit?

[TerryRitchie]

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 SUB

[SMcNeill]

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.

[TerryRitchie]

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.

Nope, no $DEBUG in use.

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

[Jack]

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

[SMcNeill]

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.)

[GareBear]

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 100

with this line it ends normally.

At 193 I get 99.8% of the circle filled before stopping.