Hollywood forums

Hi all,

I recently observed in my application some weird crashes (currently on OS3.x/AmigaForever). My first guess was, that i maybe don't have enough video memory, because i start in e-uae first workbench (800x600x32), then cubicIDE (1024x768x32) and then my application opens a display at 640x480, 800x600 or 1024x768 via hw4cubic and then a brush/Layer of double the size of the chosen display is opend by some keyboard event. The crash happens always when I open a display with 1024x768, sometimes at 800x600 and it seems there's no crash with 640x480.

The crash at 1024x768 causes a immediately crash of Hollywood/AOS3 and even euae.

The same crash happens also at 800x600 but often only when I quit my application by pressing ESC and not (always) when the huge brush/layer is opend/displayed due to the keyboard event! Weird! If I don't cause the keyboard event, then there's no crash (also not at 1024x768), so the huge layer is definitely the reason for the problem.

To see, if my assumption about low video mem is true (euae is configured to use 8 MB Picasso video mem), i started my application from shell without starting cubicIDE. After raising the stack to some high value, my application starts and and there's no crash for all resolutions. But then, i started also cubicIDE before I started my application from shell and then there was also no crash. So, low video mem is not the reason for the crashes.

Finally, i lowered the stack to some small value (4kb) and started my application from shell again. Then hollywood complains that there's not enough memory left and then AOS3 crashes.

So, it seems the stack is the problem, not the video mem.

Does someone know how to raise the stack for an application started via CubicIDE/hw4cubic?

Well, actually, the stack shouldn't be a problem because Hollywood includes stack checking code that ensures it's got sufficient space.

However, there have been some reports about Hollywood crashing when launched from Cubic. This might have to do something with the Hollywood output redirection to Cubic's message port. This is still under investigation

But you said that you also tried to start Hollywood from Shell with a stack size of 4kb and it crashed after an "Out of memory" error. This is very weird. Is this error reproduceable? Does it happen every time? Does it only happen with your script or also with some of the Hollywood example scripts?

Here's the code:

Const #WIDTH=1024
Const #HEIGHT=768

Function p_spot(x,y,w,h,type)

  CreateBrush(1,#WIDTH*2,#HEIGHT*2,#RED,{AlphaChannel=True,clear=False})
    
  RemoveLayer("spot")

  If (h>0)

    SelectAlphaChannel(1)
      SetFillStyle(#FILLCOLOR)
      SetFormStyle(#NORMAL)
      SetFormStyle(#ANTIALIAS)
      SetAlphaIntensity("0%")

      If (type="polygon")
        Polygon(x+#WIDTH,y+#HEIGHT,w,h,#WHITE,{name="spot"})
      Else
        DebugPrint("p_spot() -- type: '"..type.."' not implemented")
      EndIf

    EndSelect

  EndIf
  FloodFill(1,0,0,#WHITE,#BLACK)
  RemoveLayer("spot")
  RemoveLayer("spotbrush")
  DisplayBrush(1,x-#WIDTH,y-#HEIGHT.{name="spotbrush",transparency="50%"})

EndFunction

@VERSION        4,5
@DISPLAY { Width=#WIDTH, Height=#HEIGHT, Color = #WHITE, Title = "test"}

EnableLayers()
Local w={0,100,50,0,100,100,50,100}
Local h=4
p_spot(100,100,w,h,"polygon")

Repeat
  WaitEvent
Forever

So, it seems to be a stack issue.

From what I know, implementing recursive algorithms using stack memory is never a good idea, and you already noticed why.

Hi there,

you may have noticed that I very rarely post here, but I'd like to say - basically - one sentence about that:

So maybe I'll change the default stack size of Hollywood to 128kb for the next release. However, you could still trigger crashes by using FloodFill() on a 4096x3072 sized brush or something So the best solution is probably that you set the stack manually to the size needed

never a good idea, and you already noticed why.

For the user it's really hard to guess which algorithms are recursive and how much memory they will need in their particular application. Increasing the stack size on this is like M$ pushing the maximum partition size from 540 MB to 2 GB, then to 8 GB etc... Why don't you use an extra malloc either on each recursion or of the complete 64 kB you mentioned with a check to enlarge it when it is exhausted?