Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Serious problem with functions! (memory leak??) !!!

Author
Message
shwuckie
23
Years of Service
User Offline
Joined: 9th May 2003
Location: Australia
Posted: 16th May 2003 05:36
Link
ok try this bit of code out...



now i know and you know this is a stupid thing to do cause ya can NEVER get out of the function caling itself (there is method to my madness..) so why would i do such a thing, well, im glad you asked! i have written some code which does sort of the same thing except after its achieved its goal, it will exit the function no worries at all....

except for if it runs for too long it locks up/bombs out/crashes etc take ya pick! so i whipped this up to test if it was me or something else, and interestingly enough this snippet up here will freeze every time it hits 37034 on the count, which seems like plenty of 'loops' to get things done but sadly as i have found out its insufficient for my program when it needs to do more than that!!! if im checking an array of say 200*200 elements (and yes it is necessary for it to check internally!) thats comes to 40000, so as ya can work out for yaself 37034 is a wee bit too small for this!

ARGH!!!! is it just my machine that does this?? can someone check and see if it dies for them at this mystical 37034??? is this a problem with a memory leak with functions?? losing its place or something???

i have DB pro patch 4, DX9, and 288mb ram.

oh should warn ya, if it does hit 37034 and stop counting ya pc might do REALLY weird things, reboot if ya have too! lol

So Rich, Lee anyone!! is this fixable???
optic blast! megablast! have a blast!!
Back to top
Profile PM Email
OzBot
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: Sweden
Posted: 16th May 2003 11:46
Link
It could be that a function calling itself from within itself has a limited on the number of times it can be called (maybe runs out of allocated memory.

I am sure you would get a similar result if you kept gosubing and never returned...

I tried a similar test just now with gosub and it went well beyond 37034 however it froze when trying to exit..

I reckon it needs to exit the function at some point...

If you place the func() outside of the function in its own loop it doesn't have that problem...
Back to top
Profile PM Website
OzBot
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: Sweden
Posted: 16th May 2003 11:52
Link
How about placing a loop within the function as not call itself and do all the necessary checking before exiting.


sync on
sync rate 0
global count as integer
count=0
do
func()
loop
function func()
cls
inc count
print count
sync
endfunction
Back to top
Profile PM Website
OzBot
23
Years of Service
User Offline
Joined: 24th Feb 2003
Location: Sweden
Posted: 16th May 2003 13:44
Link
oops i meant:

sync on
sync rate 0
global count as integer
count=0

func()

function func()
do
cls
inc count
print count
sync
loop
endfunction
Back to top
Profile PM Website
shwuckie
23
Years of Service
User Offline
Joined: 9th May 2003
Location: Australia
Posted: 16th May 2003 14:59
Link
i think ya missed the point of the code i posted, altho you are totally corect this would fix this problem, thats not what i need actually.
the reason i posted that code was to show that it will crash after a while. in the real function for the program im working on, it can exit the function when it meets the exit condition.

but as i said if what im checking is a small array (say 100*100) it reaches the exit and leaves the loop, if its a bit bigger say 150*200 or vice versa, it will freeze up.

i am doing it this way because i need the value passed to the function eg func(val) to be 'remembered' when it exits inner loops and starts to get back to the start, which works well until it does a certain number of loops heres what i mean
ummm this is obviously psuedocode...

func(startval)

function func(val)

if condition(val) = true
this=that
func(val+1)
func(val+2)
func(val*2)
func(val/2)
endif
endfunction

see? thats why i need to call the function within the function
if the condition is not met it goes back out of its loop until it gets back to the original calling of the function..
this is perfectly valid in other languages i have coded in.. so why not db pro!!!

ignore those values etc, its pseudo code and is not an exact represenation of what im working on but follows the same principle

optic blast! megablast! have a blast!!
Back to top
Profile PM Email
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 16th May 2003 15:03
Link
@shwuckie

Please send an email to [email protected]

Along with source code etc. Its the only guaranteed way of bringing it to his attention. (But make sure it really is a bug first)

Do you want Windows menus in your DBP apps? - Get my plugin: http://snow.prohosting.com/~clone99/downloads/tpc_menus_102.zip
Back to top
Profile PM Email Website
Richard Davey
Retired Moderator
24
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 16th May 2003 15:40
Link
Don't bother, he already knows. Response below:

"It is a stack overflow, and can only be resolved by increasing the stack size of the main exe. In practice, stack consumption of this type should be avoided as it is very dangerous and prone to reach its limit quickly.

I have added it however as an issue for Patch 5. I might increase the
stack size a little to allow larger iterations."

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
Back to top
Profile PM Email Website
shwuckie
23
Years of Service
User Offline
Joined: 9th May 2003
Location: Australia
Posted: 16th May 2003 16:34
Link
well groovy man! i started thinking i was going nuts lol, glad it wasnt me then, altho yes i know recursive loops are a bit norty norty but it does the job perfectly for my needs! (except when it overflows lol)
does that mean there will be a command to allow us to set the stack size at the start of our code??

optic blast! megablast! have a blast!!
Back to top
Profile PM Email
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 16th May 2003 16:49
Link
The Stack size for a windows program is set at compile time - it's not a rumtime option. It would need GuyS to modify the editor to allow us to modify it. I'm assuming from Rich's and Lee's response that this will be a hard-coded change to the compiler.

I dealt with this sort of problem in my floodfill routine by doing a recode - it's still recursive. Could you not do this as well?
Back to top
Profile PM Email Website
shwuckie
23
Years of Service
User Offline
Joined: 9th May 2003
Location: Australia
Posted: 16th May 2003 17:13
Link
hmmmmm well thats exactly what ive been working on too IanM, a floodfill using memblocks, but it dies if the area to fill is too big, i cant see how to adjust it to compensate for the stack, maybe i need to define an array to hold each offset that gets hit... dunno? can i see your floodfill code to see what i should be doing to get around this? please

optic blast! megablast! have a blast!!
Back to top
Profile PM Email
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 16th May 2003 17:23
Link
Sure - it's public code.

You'll find it in here somewhere : http://www.darkbasicpro.com/apollo/view.php?t=9985&b=1

Originally, the code I was using used separate functions to recursively fill up/down/left/right. I located a better technique from the web called a 'span floodfill' that fills a line at a time, and therefore removed a whole level of recursion (left & right), and ran a darned sight faster too.
Back to top
Profile PM Email Website
shwuckie
23
Years of Service
User Offline
Joined: 9th May 2003
Location: Australia
Posted: 16th May 2003 17:45
Link
grooviness cheers for that mate

optic blast! megablast! have a blast!!
Back to top
Profile PM Email
Mentor
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 16th May 2003 20:49
Link
<evil grin> you could always rewrite the code for goto`s, go on! you know you want too!, no stack problems with goto, you can recurse all you want, goto`s are good, choose the go.... <voice fades away>...........................Muhahahaha

Mentor.

Back to top
Profile PM
Lee Bamber
23
Years of Service
User Offline
Joined: 12th Sep 2002
Location:
Posted: 24th Jun 2003 08:56
Link
In U5, the new stack size will be set to 10MB from 1MB. Ten times the freedom. In future versions of the compiler, this value will be user-adjustable. If you cannot wait there is a tool called EDITBIN.EXE which will allow you to adjust a DBPro executable to any stack size you require.

Best Regards,
Lee Bamber

Back to top
Profile PM
swdave
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United States
Posted: 24th Jun 2003 12:29
Link
Hi
This is a recursive directory parser. My current test was 16,000 folders with 160,000 files, and took 30 min. (dbExplorer...NOT)
The problem here was attempting to use db resources that dont exist. If you think a function will restore its state after calling it-self...Then think again...This problem might be more relevent to the getfiles() function, but what can I say...



Back to top
Profile PM
flibX0r
23
Years of Service
User Offline
Joined: 14th Feb 2003
Location: Western Australia
Posted: 24th Jun 2003 15:09
Link
Just a sort of irrelvant question, but why is Lee Bamber on classified as a "User"? Shouldn't it say something like creator or maker or GOD???

"But we couldn't do that Mr Flibble," questioned Rimmer. "Who'd clean up the mess?"
Twin P4 Xeon 2.0 Ghz, GeForce Quadro4 XGL 128MB, 1Gb DDR RAM, Twin 19" Flat Screens
Back to top
Profile PM Email Website
TheCyborg
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Denmark
Posted: 24th Jun 2003 17:43
Link
Or just DBS Team...

Nothing special yet --> http://thecyborg.lunaticsworld.com/
Back to top
Profile PM
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Jun 2003 20:34
Link
It's deliberate by the rest of the DBS team - it keeps Lee's head to a managable size
Back to top
Profile PM Email Website
shwuckie
23
Years of Service
User Offline
Joined: 9th May 2003
Location: Australia
Posted: 24th Jun 2003 21:06 Edited at: 24th Jun 2003 21:10
Link
man i totally forgot about this post ages ago lol!

hey IanM you know that the reason i posted this was cause my floodfill would spit it if it was too large an area to fill.

10 mb will be suffice to do it now, heres the question tho, do ya think the good old recursive fill routine will be as fast or faster than the span floodfill method, using memblocks???

hey Lee where do i get editbin.exe ???

optic blast! megablast! have a blast!!
Back to top
Profile PM Email
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Jun 2003 21:24
Link
Editbin is a utility that comes with Visual Studio.

As for your other question, the span-fill routine will almost always be faster that the standard recursive flood-fill ... especially if you give the span-fill routine a memory like I did
Back to top
Profile PM Email Website
shwuckie
23
Years of Service
User Offline
Joined: 9th May 2003
Location: Australia
Posted: 24th Jun 2003 21:36 Edited at: 24th Jun 2003 21:37
Link
groovy IanM!! btw did ya ever get yours working properly with 16 bit colour? i mean if i remember correctly yours only worked with 32 bit... correct me if im wrong please i like being wrong, proves im still australian lol

optic blast! megablast! have a blast!!
Back to top
Profile PM Email
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Jun 2003 22:07
Link
No, but then I never tried - I always work in 32 bit.
Back to top
Profile PM Email Website
Dreamora
23
Years of Service
User Offline
Joined: 20th Sep 2002
Location: Switzerland
Posted: 24th Jun 2003 22:21
Link
hmm if you have such a little stack size how about implementing real pointers like in oberon (pascal / delphi i think too) etc to work with?
then the stack wouldn't run out of mem too because a pointer has no real size not like the types the pump up a stick within short time ...

Back to top
Profile PM Email Website
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Jun 2003 22:58
Link
Pointers exist in DBPro - they are 4 bytes in size.

DBPro code


C code


Did anyone see any real difference?

Unfortunately, I'm not practiced enough with Delphi to give you code, but it would boil down to pretty much the same thing.


I've tallied up the stack usage for my own fill routine and it comes to a grand total of 28 bytes (args, local variables, stack pointer, return address).

Switching it to pointers would make it slower (memory allocation/deallocation, extra dereference required to get/set the values) and only save 4 bytes of the stack ... Hmm, maybe I won't bother changing my routine.
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2026-07-18 03:12:21
Your offset time is: 2026-07-18 03:12:21