local variables and stack

jeremywilson · Joined: 11 Jul 2011 Posts: 79 Location: United States

I recently found that if a sub/function calls another sub/function and both have local variables with the same name(s), the variables can get corrupted. It appears that because they have the same name they occupy the same stack memory location.

This is how I found the problem:

I had a sub that worked fine, but decided to make part of it a separate function. The sub no longer worked. After not being able to find the problem, I renamed the local variables in the function so they were different from the calling sub. Sub now works fine.

How do I get around this problem? I have many include files and deep call stacks. Many subs/functions use variable names like lcl_byte, lcl_word, etc...

Thanks!

P.S. On a similar note, I realized a long time ago that having a local variable with the same name as a global variable could cause problems, too.

(BASCOM-AVR version : 2.0.8.0 , Latest : 2.0.8.3 )

MWS · Joined: 22 Aug 2009 Posts: 2262

I've set up a sample code with three subs, which btw. would have been your duty to show a sample as you put these claims, and I can not confirm any of your words.

jeremywilson · Joined: 11 Jul 2011 Posts: 79 Location: United States

Strange.
My code is 13000+ lines with ten include files and is proprietary product development.
When I get time, I'll try and remove a section of code.

Thanks for checking.

I ended up changing the code and can't remember what it was.

enniom · Joined: 20 Oct 2009 Posts: 537

@jeremywilson

the above reply is nonsense. MWS caught you with your pants down and you try to hide behind 13000 lines of proprietary code and can't remember. BS.

It takes about 3 minutes to make 3 sample function/subs with the same lo LOCAL Vars to test and prove your theory.

Lesson learned.

[Edit: you also assumed that Mark would not have tested this?]

jeremywilson · Joined: 11 Jul 2011 Posts: 79 Location: United States

@enniom, thanks for the snarky reply.

Actually I really was busy (had to design a transimpedance amplifier circuit for a hydrogen sulfide sensor by end of day). The mistake I made was removing the offending code, then later thinking back on it deciding to post about it in case someone already knows about it - not to have them do the leg work of testing it for me. I was expecting someone to say "You can/can't do that in Bascom". I have been using Bascom for about twelve years now, for work and hobby. As much as I love it, I (and another fellow user) have come across some quirky things in Bascom. I have not seen these quirks in small programs, only larger ones. The problem is that these quirks don't happen very often and may occur in one program and not another. Yes, I know, neither of what I just mentioned make sense ... if you assume the compiler is perfect.

Quirks I have seen:
1) local variable with same name as global variable. (this may not be a quirk, but a rule I didn't know of)
solution: changed local variable name - problem fixed. Went back and forth with variable name to verify I wasn't crazy: problem, no problem, problem, no problem. Not crazy.

2) A sub/function calling another sub/function with local variables with the same name (only seen this once in 12 years, but...)
solution: changed local variable names - problem fixed. Went back and forth with variable names to verify I wasn't crazy: problem, no problem, problem, no problem. Not crazy.

3) I once had a compiler error that I eventually isolated to a variable initialization (e.g. X=10). Deleted and retyped the line - still error. (my friend could not compile and could not understand error either)
Deleted and retyped all variable initializations - still problem. There was clearly nothing wrong with the code.
solution: cut and pasted the whole block of initializations code into Notepad, then cut and pasted back to Bascom - problem fixed. No more compiler error. Was there invisible code in there (there were no blank lines)???

4) I had a program with the interrupt service routines located at the bottom of the listing. As the code got long, one ISR stopped working. Maybe there's a memory bank requirement I'm not aware of.
solution: cut and pasted ISRs near top of listing - problem fixed.

5) I had a program with the interrupt service routines located near the top of the listing (after declarations and includes). There was no problem with code (cut and pasted code from my existing code that had no problems).
solution: physically re-ordered ISRs and subs (no change to logic or program flow) - problem fixed.

6) Programs with subs inexplicably not working correctly. Simple code - clearly no errors. I come across this problem three or four times a year.
solution: cut and paste sub to another location (no change to logic or program flow) - problem fixed.

How do I know they were problems and how do I know they were solved? Lots of testing.

Feel free to comment on why the problems existed and why the solutions worked.

By the way, this forum has been a great resource for me and I appreciate everyone's feedback, but keep in mind this forum is not for people who know everything, so don't be a gatekeeper!

enniom · Joined: 20 Oct 2009 Posts: 537

Please consider removing the flag from your personal profile ... it makes it difficult for the rest of us.

E

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

I usually do not reply to posts where there are claims without code. On top of that using an old version will also not help.

1: when you create a local with the same name as a global you ask for problems. the compiler will handle it, but you the programmer need to watch out : when you assign a variable inside a sub/function and you think you assign a global, but a local variable with the same name exist, you will assign the local. Since the compiler will first check for a parameter, then for a local and last for a global.
For this reason Hungarian notation exists. Use a prefix like g for global, and l for locals.
Or simply take care of what you do.

2: this will work unless you have some error. the only possible error is when you used a function that was not able to handle a local correct. i dont recall which function this was, but it was fixed. if you do not report a problem then such problems will not be fixed. it is simple : as soon you have some error you can not explain, save a copy of all code and also of the configuration file. and send it to support. better to reduce the code and excellent is when it can be simulated. but to ignore it is not good at all.

3: in the editor you can turn on invisible code. some times however people confuse 0 with 0 or l with 1. check with a hex viewer to see the problem. but again , see point 2 !

4-5-6: the point is irrelevant. only it should obey the coding rules. often i see code walking into a routine, or not using config submode=new. but again see 3.

when you see the history you can notice that there are always new functions and new processors but also bug fixes. i do not claim it is all perfect. in order to make it better you should always update and always report problems.

i would also advise to re-read the help/pdf especial when you are a long time user. often new info is added that was not available 20 years ago.
i would appreciate it that claims of problems come with some code in the future. Either here or at support.
In many cases, a problem is just something a user overlooked because he get blind for the code. But in case of a bug it is in all our interest to fix it.

jeremywilson · Joined: 11 Jul 2011 Posts: 79 Location: United States

Thanks for the info, Mark.
I will post code the next time I see a "quirk".

Duval JP · Joined: 22 Jun 2004 Posts: 1161 Location: France

JC · Joined: 15 Dec 2007 Posts: 586 Location: Cleveland, OH

Jeremy, I'm sure you are already aware of this, but perhaps a reminder would be OK.

Especially with large programs, with lots of Subs and ISRs, which call other Subs, …
Make sure that your $Stack settings are large enough.
A stack overflow problem can be very challenging to identify unless you keep it in mind as a possible problem, (with an easy solution!).

Regarding the reordering of code to fix a problem:
"Everyone" knows that's crazy, because the compiler is deterministic in operation, it makes its passes, makes its list, processes the code, etc.
That said, I seem to recall having seen this once before myself.
I moved things around and it suddenly worked.
At the end of the day, however, IIRC, there was another underlying bug / problem with my code.
When that was identified and corrected, then the ordering made no difference, (as in fact it shouldn't).
It, also, was a "large" program, (A GPS project with the route shown on a GLCD...).
I remember thinking how odd that problem was, until I found the real problem.

Another challenging bug to find involved ISRs.
The age old adage is to keep ISRs short, set flags, etc., and do the processing in the Main Loop.
But sometimes the program is just more easily structured with the code within the ISR, and a minimalistic Main Loop.
If you know when the ISRs are firing, and their processing duration, that approach is fine, especially with the 3 level priority interrupt controller within the Xmega and the two level priority controller within the new DA and DB chips.

That said, the ISR invocation doesn't push and pop all of the registers, especially if using Floating Point within the ISR.
Its all in the Help section, but it is easily overlooked, if one only attempts to do that once every few years.

Be careful with the H2S sensor testing!
Remember that H2S will quickly deaden your sense of smell to it, so you don't know you are being exposed!
Levels to cause harm are pretty low!

Good luck with your projects!

JC

jeremywilson · Joined: 11 Jul 2011 Posts: 79 Location: United States

@JC