when variables go bad?

Status
Not open for further replies.

virtualdave

Well-known member
Not a bug, just a "what the...?" ...and really just curious if anyone else had seen anything like this.

So I have a sketch that I've been essentially editing for several months. Suddenly tonight I noticed something wasn't triggering that should have (and has since the first version of the sketch), so printed out the current values and am now scratching my head. Here's the low-down:

I have 2 variables, pressureRingMin & pressureRingMax. Both unsigned longs and hold calibration values for one of the analog inputs. By default these are set to 8500 & 16000, respectively. However when I noticed things weren't working right, the values that were reported were 808333360 875771952, respectively. Again, up till tonight these values would have been reported correctly. If I go through the calibration sequences (resetting the min & max values), everything works fine and new (and correct) min/max values are recorded correctly. Having had variable naming issues in the past with simpler variable names (conflicts with other libraries, I suppose), I did a global change from pressureRingMin to pressureRingMn & pressureRingMax to pressureRingMx, and voila...I'm back in business. But why, I have no idea. I don't think it's the "Min" and "Max" suffixes since those show up in many other variables (e.g. pressurePointerMin, pressurePointerMax). I should be happy that I at least have a solution, but it drives me a bit nuts, and my programming OCD isn't happy that some of my variables end in "Min" and one in "Mn" :)

Anyway...was curious if anyone else had come across something like this in their Arduino past.

Thanks for reading!
David
 
Last edited:
When I've seen problems like this, and believe me, I have several times, it's usually a bug in some interrupt routine that's overwriting memory it shouldn't. Computing a bad index to an array (a buffer overflow) is the most common. It can be tricky to troubleshoot, because as you try other things by adding or removing code, the linker assigns different variables to the overwritten memory.

Then again, the bug doesn't necessarily have to be in an interrupt. Pretty much any code can write to anywhere. It's a tough problem to diagnose.
 
One of the first things I do when faced with a problem like this, is to take your numbers and convert them to hexadecimal.

808333360 = 0x302e3030 and since the teensy is little endian, this becomes 30 30 2e 30 when looking at raw memory. This happens to correspond to the ASCII characters "00.0"

Similarly, 875771952 = 0x34333830 which in memory looks like 30 38 33 34 which corresponds to the ASCII characters "0834"

So I'd guess that you have a buffer overrun happening, or an invalid pointer being used to store a string, or something along those lines.

The most common thing is that some buffer, typically earlier in memory, is being overflowed. If your calibration values are stored as globals, then you can use the memory map to look at variables earlier in memory that your calibration values.

When compiling with a makefile, I add
Code:
-Wl,-Map,somename.map
to the linker command line to get a map file. I'm not sure what your options are when using an Arduino Sketch.
Perhaps teensy-template could be of assitance here?

If you can get at the .elf file, then you can use
Code:
nm -n somefile.elf
to get a sorted list of global variables/functions by address.
 
Very helpful! Thanks for the pointers (no pun intended...really...)

But I'm still a bit baffled why doing a global change of the variable name in my sketch (i.e. dropping or adding a single letter to the variable name) fixes everything. I'm getting over it since it seems to work fine, but still scratching my head.
 
Maybe the linker is assigning things to different locations?

Or perhaps whatever code is overwriting the memory only strikes infrequently, randomly, or in some other way that at first gives the impression the problem is solved, but will later corrupt those variables again.

Some code somewhere in your project is almost certainly overwriting other variables. These problems can be tough to track down, but until you do, you'll probably see all sorts of strange, difficult to troubleshoot failures. Memory corruption is pretty terrible like that.
 
OK. And I should know better from experience, too, that my "fix" probably isn't a fix. Any troubleshooting pointers within the arduino environment that might help me watch this more carefully along the lines of what @dhylands recommends with the makefile?
 
Very helpful! Thanks for the pointers (no pun intended...really...)

But I'm still a bit baffled why doing a global change of the variable name in my sketch (i.e. dropping or adding a single letter to the variable name) fixes everything. I'm getting over it since it seems to work fine, but still scratching my head.

Well, that sounds like the classic "uninitialized pointer" behaviour. This is notorious for stack variables. If they're uninitialized, then they just get whatever random data happens to be on the stack leftover from previous functions running.

uninitialized pointers and writing to memory you're not supposed to are probably 2 of the most common pitfalls for C/C++ programmers. You need to remember that a pointer, in and of itself, has NO storage. You always have to point it at some storage before you us it, and you need to make sure that the storage is big enough to hold whatever you're going to store there.

If you have a small example that's misbehaving, I could take a quick look at it to see if anything jumps out at me.
 
Without seeing your code it is hard to diagnose the problem but one thing you can do is in the IDE menu select Files|Preferences and set "Show verbose output during: Compilation".
Then track down and fix all the warning messages.

Pete
 
Careful desk-check of code usually gets it. As said above. Maybe print on hardcopy so it'll jump out at you.
 
Not a bug, just a "what the...?" ...and really just curious if anyone else had seen anything like this.

So I have a sketch that I've been essentially editing for several months. Suddenly tonight I noticed something wasn't triggering that should have (and has since the first version of the sketch), so printed out the current values and am now scratching my head. Here's the low-down:

I have 2 variables, pressureRingMin & pressureRingMax. Both unsigned longs and hold calibration values for one of the analog inputs. By default these are set to 8500 & 16000, respectively. However when I noticed things weren't working right, the values that were reported were 808333360 875771952, respectively. Again, up till tonight these values would have been reported correctly. If I go through the calibration sequences (resetting the min & max values), everything works fine and new (and correct) min/max values are recorded correctly. Having had variable naming issues in the past with simpler variable names (conflicts with other libraries, I suppose), I did a global change from pressureRingMin to pressureRingMn & pressureRingMax to pressureRingMx, and voila...I'm back in business. But why, I have no idea. I don't think it's the "Min" and "Max" suffixes since those show up in many other variables (e.g. pressurePointerMin, pressurePointerMax). I should be happy that I at least have a solution, but it drives me a bit nuts, and my programming OCD isn't happy that some of my variables end in "Min" and one in "Mn" :)

Anyway...was curious if anyone else had come across something like this in their Arduino past.

Thanks for reading!
David

Hi David,

Just curious, because I had similar problem before, do you use things like #pragma pack inside your program? I used to have one pack 1 while the others not packed, and I have very similar problem, though the number is much larger, around 0xffffff80 to 0xffffffff.

I tried to apply pack only around structure definition and I have yet to observe a bad variable for some time.

Meanwhile another thing you might want to check is that if you have enum values greater than 0xff, it would have problem linking to other object as gcc-arm default using -fshort-enums which may cause problem in alignment.

Hope it gives you some hint.

Regards,
Bai Shi
 
Thank you all for your feedback. Let me whittle this down to something helpful to post. The sketch is 2600+ lines...don't think that'll be helpful to post :)

@el_supremo: never knew about that option! Uncovering at least one other thing I missed.

@baishi: no, not using anything like that.

David
 
Status
Not open for further replies.
Back
Top