Functions in functions cause random memory errors

BlitzMax Forums/BlitzMax Programming/Functions in functions cause random memory errors

JoshK(Posted 2007) [#1]
I have been struggling with a problem for two days. Somewhere some of my code is randomly overwriting memory that happens to be in a block of memory where some texcoords are stored. The error changes depending on what unrelated parts of code I compile, so it is definitely one of those untraceable memory problems. I'll make a change that fixes it, then a few hours later it pops up again.

The only time I have ever seen this happen in BlitzMax is when functions within functions were used, with a global variable in the main function called in the nested function.

The only thing I can think to do is go through all my code and eliminate all functions in functions. This is not a trivial task.


Dreamora(Posted 2007) [#2]
you could as well cut the globals in the main functions, make them local and pass them.

This would guarantee that the frame pointer in the stack are not beeing messed up by the global ...

Don't know what steps BM actually takes for its func in func feature, but due to the GC, "local globals" and real globals there is a lot of potential to mess with the stack.

This is assuming that you are not calling func in func recursively, as this most likely guarantees that it will mess.

And it is a trivial task actually.

cut - paste, rename to mainfunction_subfunction(...) and you are done

By using regex / macro this potentially can even be automated


JoshK(Posted 2007) [#3]
I have no idea what is happening. I keep making changes, the problem goes away, then it reappears again later.


N(Posted 2007) [#4]
You shouldn't be using nested functions, just so you know. It's more of a neat side-effect than anything supported. In short, expect some degree of stack corruption if you're doing anything that shouldn't be done.

Of course, it could be that code buried in some deep, dark horrible section of whatever it is this is about is writing past what it should be. Brings back memories of people using strcpy in C...


REDi(Posted 2007) [#5]
You shouldn't be using nested functions

I might be wrong but I swear I've seen nested functions in the BRL modules somewhere.
*EDIT* cant seem to find any now tho


dmaz(Posted 2007) [#6]
I use funcs within funcs a lot without any problems. I would have to go back and check if I use globals from the parent func though...


grable(Posted 2007) [#7]
Are you accessing any variables outside its scope? Like fields if the function is inside a method?

If you treat them as any other global function (which they are really) there shouldn't be any problems.


JoshK(Posted 2007) [#8]
I am not sure this is the cause, but it is the only thing I have ever seen cause silent memory errors like this.

Every time I change something just to help debug the problem, the problem goes away, then reappears later.


Will(Posted 2007) [#9]
I've experienced random problems like this before - never figured it out though, now that I know it might be a function-in-function issue I hope I'll be able to resolve it.


TaskMaster(Posted 2007) [#10]
What the heck is function in function? Nested functions?


Brucey(Posted 2007) [#11]
What the heck is function in function

I think you mean, what is this nonsense? ;-)


ImaginaryHuman(Posted 2007) [#12]
Yah, never heard of this capability. How does it even make sense? Like, a local function which only the parent function can call?


Dreamora(Posted 2007) [#13]
Correct.
This function is only known to its parent function.

The only potential reason to do such a suicide attempt to "opt code" is cases where you want a sub function to use the same variable as the main function.

The reason for this thing most likely is that goto / gosub do not exist anymore which allowed this kind of stuff without nested functions.

But even then: its a very bad programming style to use this kind of functionality as the program flow becomes less clear and potentially even corrupted if you ever try to visualize it in some kind of usage case or the like to explain to someone else what it does.
So my above suggestion with mainfunction_subfunction would allow a far clearer structuring (and potential reuse)

The only place I know this feature was ever used was the brl.gl module where it was used in the calctexsize to get the nearest power of 2 value.