|
|
|||||||
I am receiving the following error in Kix32 version 4.64:- Stack overflow exception. The common cause for this type of exception is an endless recursive loop. Please check your script(s) for endless loops. If I run my program with kix32 version 4.53 my program works. Basically, I am using a recursive function to fill a graphic area. Code: Function FillBill($x, $y, $f, $r) ; If pixel colour at ($x,$y) is $f replace it with colour $r If $form.point($x, $y) = $f Dim $c $c = $form.forecolor ; Save Forecolor $Form.forecolor = $r $form.pset($x, $y) FillBill($x+1, $y, $f, $r) FillBill($x-1, $y, $f, $r) FillBill($x, $y+1, $f, $r) FillBill($x, $y-1, $f, $r) $form.forecolor = $c ; Restore Forecolor Endif What is different with the latest version of kix32.exe from previous versions as regards to memory usage? Please ignore the fact that the actual coding above does not fill in pixels in the 4 corner positions around the target pixel. It's only a test script. I'm also using Kixforms 2.47.5. Regards, |
||||||||
|
|
|||||||
Further testing has revealed that this error was introduced in Kix32.exe versions 4.62 and 4.63. Versions 4.60, 4.61 do not produce this error with my recursive fill function. Please fix in 4.65. Cheers, |
||||||||
|
|
|||||||
uh oh... function calling itself sounds like infinite loop waiting to happen... have you tried outputting something on the console to see how many times it is ran? say, add a global var $test_runs = 0 at the start of your script and modify your fillbill to: Code: Function FillBill($x, $y, $f, $r) ; If pixel colour at ($x,$y) is $f replace it with colour $r If $form.point($x, $y) = $f $test_runs=$test_runs+1 chr(13) $test_runs Dim $c $c = $form.forecolor ; Save Forecolor $Form.forecolor = $r $form.pset($x, $y) FillBill($x+1, $y, $f, $r) FillBill($x-1, $y, $f, $r) FillBill($x, $y+1, $f, $r) FillBill($x, $y-1, $f, $r) $form.forecolor = $c ; Restore Forecolor Endif what is the number at when it crashes? |
||||||||
|
|
|||||||
Hi Lonkero, I've created a simpler recursive function that produces a count. Code: break on $ = setoption("wrapateol","on") recurs(1) ? return function recurs($i) If $i<100000 $i " " recurs($i+1) endif endfunction Kix 464 bombs out at 2116 whilst 453 bombs at 8356. So this older version seems to have 4 times more stack space. 460, 461 both bomb out at 23768 462, 463 at 2169 So I think versions 460 and 461 had a lot more going for them. Cheers, |
||||||||
|
|
|||||||
what kind of memory usage we are talking about at that point? indeed 2116 sounds really low. |
||||||||
|
|
|||||||
The above program is all there is too it. A couple of variables and one function. 4.64 runs out of stack space quite quickly. Perhaps it needs to be more dynamic in the allocation of heap and stack space. In Task manager you see Kix32 start briefly at 15,000K to 45,000K then as it terminates it displays 75,464K Kix32 453 terminates at 259,820K Kix32 460 terminates at 834,748K So 4.64 must be under resourced. Cheers, |
||||||||
|
|
|||||||
I do not know why this is, maybe it's something Ruud has changed or maybe the defaults for the new visual studio version is different. anyways, you can fix it by issuing: editbin /stack:99999999 wkix32.exe when you issue the command, editbin actually modifies the executable and this issue is fixed. http://msdn.microsoft.com/en-us/library/xd3shwhf.aspx install visual studio (express is fine) if you do not have it yet to use this tool. |
||||||||
|
|
|||||||
Thanks Lonkero, does this also work on kix32.exe ? Happy Kixmas, |
||||||||
|
|
|||||||
It works for any exe |
||||||||
|
|
|||||||
Thanks. Now got to find that Virtual Machine with all my test apps on. |
||||||||
|
|
|||||||
Hi Lonkero, I can't find editbin.exe in Visual Studio Express 2010. I suppose I'll have to try 2013. Cheers, |
||||||||
|
|
|||||||
Hmm... I do also have windows 7 SDK on that computer. Might be it as well. |
||||||||
|
|
|||||||
Thanks for this report, seems like I decreased the size of the stack somewhere. I'll look at this for the Windows 10 update. Ruud |
||||||||
|
|
|||||||
hopefully that windows 10 update will also fix the failing move, del and rd... thanks for staying with it, Ruud! |
||||||||
|
|
|||||||
I haven't tested this with 4.67 beta, but I just ran out of memory with 4.66 trying to read a line from 800 meg text file... |
||||||||
|
|
|||||||
Thanks for the heads up, I'll have a look to see what's up. Can't promise I'll be able to fix in 4.67 as I want to release that in the coming days, but let's see. Ruud |
||||||||
|
|
|||||||
Ok, did some more tests: the stack in 4.62 through 4.65 was indeed (too) small. In 4.66 and 4.67 it is larger than ever, and for example the recursive script above can achieve 52994 iterations. So I'm considering this issue fixed. If anyone still has a reproducible problem: please start a new topic. Ruud |