I'm getting a "Error allocating stack memory" error message when trying to parse a $findfile within a while loop (300 times{300 folders} for 7000 odd files) it's performing aline @window $nopath($1-) for each file within the $findfile identifier itself. then filtering the window to a file.

I know its not the filtering because it can handle way more than 7000 lines.... so....

What could be causing this, I'm almost sure it's to do with the number of folders because it worked fine with the same number of files within only 164 folders(and tested tonight for a similar number of files on 250 folders)

What is stack memory? Is it like stacks where everything goes on top and to get to the bottom data you need to remove all the top stuff? Is there a workaround or do I just parse every 250 folders worth??


%billy.num is incremented in another alias and then passed to this one...
it's not a while loop but it does keep calling the alias once it's parsed and until %billy.num is maxed.

%billy is unset at the end of each folder(which can be one file or 5000)

(why do i get the feeling i've confused everyone!)

btk

You've got the right idea regarding the stack memory, although in reality it works in reverse to what you're thinking. The information is stacked on top of each other, so the oldest information is closest to the bottom. In theory (and normally in practice) when the stack gets to about 95% full, then the oldest info (the stuff on the bottom) is pulled out making room for more on top. It's been a while since I've looked at/referenced the exact numbers, but 95% of full sounds about right.

Most of the time if that message comes up, rebooting the computer then trying the code again is sufficient to clear the problem. If this is happening constantly, then you may need to parse every 250 folders (since you've determined that 250 does work).

thanks for that, i did reboot after about 9 hours of pulling my hair out only to be greeted by the same thing on next check, however i have disabled the auto-clean on bootup thingy that might fill some stack space, will try again.

thanks for the info, wish it was different though! lol eugh...


and why is memory aloocated like this, cant i have a tree instead??
btk

would allocation to a hash table be better, then pass that to the .txt file? or would the same error occur do you think? that'd be slower than a /filter anyhow wouldnt it?

btk

The memory allocation is Windows based, not anything to do with mIRC. (ie: Blame Microsoft (again..LOL))

As to using a hash table, I honestly don't know and I don't have sufficient files/directories to be able to test a code to see if it would work or not, but as you noted, it probably would be slower than using the /filter (too bad you couldn't combine the two)..

Good luck, and if you decide to try the hash table idea, let us know how (and if) it works, others might need/want the information later.

This has nothing to do with Windows. The error you get is displayed when a script exceeds the maximum alias call depth (1000 or 500, depending on how you call the alias): in the vast majority of cases, this is due to a mistake in the script itself, which results in infinite recursion. As I don't think you even need (or meant to use) recursion in your script, you'll have to show us all the aliases involved in this operation (not just the $findfile line).

Regarding your $findfile, the third parameter is supposed to be a number, not a wildcard. You need 0 instead of * in there. Although any non-numeric string defaults to 0 in most such cases, you should use the proper syntax.

This is definitely incorrect for "most of the time" and should not be presented as a solution, especially when that solution is as drastic as a reboot. I have never seen this message caused by anything other than script errors. I wonder though, has it ever happened to you (the exact same script run on the exact same data being fixed after a reboot)?

I've never seen this error via a script, but I have seen it come up with programs (executables) that have had problems, and in all cases when I've seen that error the recommendation has been to reboot. I tried just re-running program a couple of times when I first saw this error and my computer locked up completely. So my statement was based on my own experience. If others have had a different experience, then so be it. I can only speak from my own knowledge and experience.

I know its really easy to reproduce with just a few characters and $() usage. Forgot how to though :P

//tokenize 32 $!($1,2) | echo $($1,2)

is one way (again a script error of course). This is one of the rare cases where an external alias isn't involved, although an internal one is: $eval()/$() is a sort of internal alias that uses $evalnext().

ahh yes that was it

That would definately be the cause, i do have one alias calling another in a recursive manner until a variable is reached, that's explain why it works with less folders(the alias is called less times). If I change this to a while loop then this should be fixed.... will get right on it...

I noticed the asterisk in there and changed it to 0,1 anyhow, as I was wanting to limit the depth as well....

Thanks for this.
btk

thanks everyone for your advice. Changing the recursive alias call(itself called from within another alias) to a while loop sorted it out. That's what I get for using old code I wrote about 6 years ago...

Many thanks, now where do I get cream for the bald patches this has caused....

:tongue: