Note: This is an archived post that was originally sent to the Hollywood mailing list on Tue, 06 Apr 2010 15:20:06 -0000
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?
Thanks! Tom
[06 Apr 2010] Hollywood/hw4cubic with stack problems -> crash?
- airsoftsoftwair
- Posts: 5832
- Joined: Fri Feb 12, 2010 2:33 pm
- Location: Germany
- Contact:
[06 Apr 2010] Re: Hollywood/hw4cubic with stack problems -> crash?
Note: This is an archived post that was originally sent to the Hollywood mailing list on Tue, 06 Apr 2010 22:26:07 +0200
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?
Well, actually, the stack shouldn't be a problem because Hollywood includes stack checking code that ensures it's got sufficient space.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?
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?
[07 Apr 2010] Re: Hollywood/hw4cubic with stack problems -> crash?
Note: This is an archived post that was originally sent to the Hollywood mailing list on Wed, 07 Apr 2010 06:24:35 -0000
1) Run via CubicIDE at a resolution of 1024/768
-> crash of AOS3 and euae.
2) run from shell with 2kb stack
-> request opens to let me know, if i want to run it at full screen, because workbench is at 800x600
-> choosing 1024x768x32 bit mode
-> not always a crash (sometimes by closing ths script with CTRL-C)
3) run from shell with 2kb stack but with cubicIDE started in background at 1024x768x32
-> immediate crash of aos3 and euae
4) run from shell with 10.000.000 stack and with cubicIDE stated in background at 1024x768x32
-> no crash at all
So, it seems to be a stack issue.
Yes, it's reproducable here. I added some code below which shows the following behaviour.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?
1) Run via CubicIDE at a resolution of 1024/768
-> crash of AOS3 and euae.
2) run from shell with 2kb stack
-> request opens to let me know, if i want to run it at full screen, because workbench is at 800x600
-> choosing 1024x768x32 bit mode
-> not always a crash (sometimes by closing ths script with CTRL-C)
3) run from shell with 2kb stack but with cubicIDE started in background at 1024x768x32
-> immediate crash of aos3 and euae
4) run from shell with 10.000.000 stack and with cubicIDE stated in background at 1024x768x32
-> no crash at all
So, it seems to be a stack issue.
Code: Select all
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
- airsoftsoftwair
- Posts: 5832
- Joined: Fri Feb 12, 2010 2:33 pm
- Location: Germany
- Contact:
[09 Apr 2010] Re: Re: Hollywood/hw4cubic with stack problems -> crash?
Note: This is an archived post that was originally sent to the Hollywood mailing list on Fri, 09 Apr 2010 21:53:57 +0200

The problem is your call to FloodFill(). Flood filling is implemented using a recursive algorithm and you are attempting to flood fill a brush of 2048x1536 pixels which is too much for Hollywood's builtin stack size which is set at 64kb. If I increase the stack size to 128kb, the crashes are gone.
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 
Ok, you're right... it is a stack issueSo, it seems to be a stack issue.
The problem is your call to FloodFill(). Flood filling is implemented using a recursive algorithm and you are attempting to flood fill a brush of 2048x1536 pixels which is too much for Hollywood's builtin stack size which is set at 64kb. If I increase the stack size to 128kb, the crashes are gone.
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
-
bistullapagredo
[10 Apr 2010] Re: Re: Re: Hollywood/hw4cubic with stack problems -> crash?
Note: This is an archived post that was originally sent to the Hollywood mailing list on Sat, 10 Apr 2010 00:42:55 +0100
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 
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?
Just my 2ct., good night.
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
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...From what I know, implementing recursive algorithms using stack memory is never a good idea, and you already noticed why.![]()
Just my 2ct., good night.
- airsoftsoftwair
- Posts: 5832
- Joined: Fri Feb 12, 2010 2:33 pm
- Location: Germany
- Contact:
[11 Apr 2010] Re: Re: Re: Hollywood/hw4cubic with stack problems -> crash?
Note: This is an archived post that was originally sent to the Hollywood mailing list on Sun, 11 Apr 2010 18:38:10 +0200
Of course, dynamic stack enlarging would be the smoothest solution but considering that Hollywood is a multiplatform/partly hybrid CPU app (lots of the processing algorithms run on the PPC context on WarpOS) it surely would mean a lot of work to improve things here. And AFAICS, crashes caused by small stack size are not a problem at all. In fact, this is the only report I ever got about this 
Easier said than doneHi 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 somethingSo 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?