Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

local variables and stack

 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message
jeremywilson

Bascom Member



Joined: 11 Jul 2011
Posts: 59
Location: United States

usa.gif
PostPosted: Thu Sep 03, 2020 5:32 pm    Post subject: local variables and stack Reply with quote

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 )
Back to top
View user's profile AIM Address
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1830

blank.gif
PostPosted: Thu Sep 03, 2020 7:56 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
jeremywilson

Bascom Member



Joined: 11 Jul 2011
Posts: 59
Location: United States

usa.gif
PostPosted: Thu Sep 03, 2020 9:22 pm    Post subject: Reply with quote

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.
Back to top
View user's profile AIM Address
enniom

Bascom Member



Joined: 20 Oct 2009
Posts: 474

PostPosted: Sun Sep 06, 2020 12:37 pm    Post subject: Reply with quote

@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?]
Back to top
View user's profile
jeremywilson

Bascom Member



Joined: 11 Jul 2011
Posts: 59
Location: United States

usa.gif
PostPosted: Sun Sep 06, 2020 5:24 pm    Post subject: Reply with quote

@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!
Back to top
View user's profile AIM Address
enniom

Bascom Member



Joined: 20 Oct 2009
Posts: 474

PostPosted: Sun Sep 06, 2020 6:44 pm    Post subject: Reply with quote

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

E
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5093
Location: Holland

blank.gif
PostPosted: Sun Sep 06, 2020 8:31 pm    Post subject: Reply with quote

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.

_________________
Mark
Back to top
View user's profile Visit poster's website
jeremywilson

Bascom Member



Joined: 11 Jul 2011
Posts: 59
Location: United States

usa.gif
PostPosted: Sun Sep 06, 2020 10:25 pm    Post subject: Reply with quote

Thanks for the info, Mark.
I will post code the next time I see a "quirk".
Back to top
View user's profile AIM Address
Duval JP

Bascom Member



Joined: 22 Jun 2004
Posts: 947
Location: France

france.gif
PostPosted: Mon Sep 07, 2020 10:45 am    Post subject: Reply with quote

Quote:
1: when you create a local with the same name as a global you ask for problems.


when I need a local variable that will turn into a global sub in I name it with the same name to which I add Fx (false)

dim mystring 'in the main program
----

local fxmystring ' in the sub
fxmystring = "xxxx
mystring=fxmystring

When I debug, it's easy to search for the local "fxmystring" or both "mystring" even in a big program.

JP : wink :

_________________
pleasure to learn, to teach, to create
Back to top
View user's profile Visit poster's website
JC

Bascom Member



Joined: 15 Dec 2007
Posts: 490
Location: Cleveland, OH

usa.gif
PostPosted: Mon Sep 07, 2020 7:11 pm    Post subject: Reply with quote

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
Back to top
View user's profile Visit poster's website
jeremywilson

Bascom Member



Joined: 11 Jul 2011
Posts: 59
Location: United States

usa.gif
PostPosted: Mon Sep 07, 2020 10:33 pm    Post subject: Reply with quote

@JC

Quote:
Make sure that your $Stack settings are large enough.

I use the stackcheck.lib to periodically check my usage. Whatever it says I'm using for software, hardware and frame, I usually give double that amount. My soft and hard stacks are currently using about 40 out of 100, and frame is using about 2000 out of 4000.

Quote:
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.


The last time I had the issue (and I was quite certain there was no error), I just commented it all out. Then continued adding on the rest of the program towards completion. Then later uncommented it and it worked fine.
It's not logical and I don't understand it, but if the code had errors it wouldn't matter where or when you put it in. In my mind, there may be something very subtle in the parsing of the text. ???
Bascom is an incredible piece of software with an amazing library of functions (and a great forum), so I don't sweat the small stuff.


Quote:
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!

We've been manufacturing parts-per-million H2S analyzers for the oil & gas industry for about ten years now. 100 PPM of H2S will kill you, but luckily 0.1 PPM stinks to high heaven of rotten eggs. We test these in vent hoods, but you can still smell a tiny leak.


Code:
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.
 

For sure! I always keep them short and sweet. You need good control of interrupts when you have multiple hardware RS485 ports plus keypad debouncing (with multi-keypress functions) and measuring all the sensors in the background and logging it to the SD card without missing a beat.
Back to top
View user's profile AIM Address
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum