Function call is corrupted when compiled for debug (rustc 1.82.0-nightly (c1a6199e9 2024-07-24))

[hankertrix]

I don't have a minimal reproduction, as this issue disappears when I remove one function call from my loop function, specifically, a call to the dispatch_commands function in my code, which is linked below.

The full code is here.

I suspect the Arduino might be running out of memory in debug mode, but I cannot confirm, and I have no idea how to debug it. I am using an Arduino Mega 2560. Below is the output of the avr-size command for the binary in debug mode:

   text	  data	   bss	   dec	   hex	filename
  26856	  2610	     9	 29475	  7323	arduino-cone-layer.elf

Below is the output of the avr-size command for the binary in release mode:

   text	  data	   bss	   dec	   hex	filename
  24186	  1800	     9	 25995	  658b	arduino-cone-layer.elf

My code essentially moves a car, so there are four movement motors for the four wheels. The main loop runs the four movement motors every loop. Below are the logs for the expected result, in release mode, running the loop 4 times:

Arduino initialised!
Dispatching commands
Dispatching commands
Commands dispatched
Running movement motor no. 1
Running movement motor no. 2
Running movement motor no. 3
Running movement motor no. 4
Motors run

Dispatching commands
Dispatching commands
Commands dispatched
Running movement motor no. 1
Running movement motor no. 2
Running movement motor no. 3
Running movement motor no. 4
Motors run

Dispatching commands
Dispatching commands
Commands dispatched
Running movement motor no. 1
Running movement motor no. 2
Running movement motor no. 3
Running movement motor no. 4
Motors run

Dispatching commands
Dispatching commands
Commands dispatched
Running movement motor no. 1
Running movement motor no. 2
Running movement motor no. 3
Running movement motor no. 4
Motors run

In debug mode, however, it seems like the function to run the motors has been corrupted, as shown in the logs below:

Arduino initialised!
Dispatching commands
Dispatching commands
Commands dispatched
Running movement motor no. 1
Running movement motor no. 2
Running movement motor no. 3
Running movement motor no. 4
Running movement motor no. 5
Integer overflow: current time - previous step time
Running movement motor no. 6
Integer overflow: current time - previous step time
Running movement motor no. 7
Integer overflow: current time - previous step time
Running movement motor no. 8
Running movement motor no. 9
Running movement motor no. 10
Integer overflow: current time - previous step time
Running movement motor no. 11
Integer overflow: current time - previous step time
Running movement motor no. 12
Integer overflow: current time - previous step time
Running movement motor no. 13
Integer overflow: current time - previous step time
Running movement motor no. 14
Integer overflow: current time - previous step time
Running movement motor no. 15
Integer overflow: current time - previous step time
Running movement motor no. 16
Integer overflow: current time - previous step time
Running movement motor no. 17
Integer overflow: current time - previous step time
Running movement motor no. 18
Integer overflow: current time - previous step time
Running movement motor no. 19
Integer overflow: current time - previous step time
Running movement motor no. 20
Integer overflow: current time - previous step time
Running movement motor no. 21
Integer overflow: current time - previous step time
Running movement motor no. 22
Integer overflow: current time - previous step time
Running movement motor no. 23
Integer overflow: current time - previous step time
Running movement motor no. 24
Integer overflow: current time - previous step time
Running movement motor no. 25
Integer overflow: current time - previous step time
Running movement motor no. 26
Integer overflow: current time - previous step time
Running movement motor no. 27
Integer overflow: current time - previous step time
Running movement motor no. 28
Integer overflow: current time - previous step time
Running movement motor no. 29
Integer overflow: current time - previous step time
Running movement motor no. 30
Integer overflow: current time - previous step time
Running movement motor no. 31
Integer overflow: current time - previous step time
Running movement motor no. 32

There are integer overflows for subtracting the previous step time from the current time as well, which should not happen as the previous step time is initialised to 0.

I think this is most likely memory corruption due to the Arduino running out of memory, but I don't know how to get the memory usage of each function call or even the total memory used by the program, so I'm not sure where to start optimising either.

Does anyone have any idea on how to fix this issue?

[Rahix]

Please always use the following build profiles to ensure even debug code gets optimized:

avr-hal/Cargo.toml

Lines 1 to 11 in 544e50b

	[profile.dev]
	panic = "abort"
	lto = true
	opt-level = "s"
	[profile.release]
	panic = "abort"
	codegen-units = 1
	debug = true
	lto = true
	opt-level = "s"

Beyond that, the only difference between debug and release should be the presence of overflow-checks and debug-assertions. These can blow up code size a bit due to the additional panicking code paths.

You can try "optimizing" against them by ensuring panicking code-paths cannot be reached. For example, by doing appropriate bounds checks on values before performing arithmetic, or by using methods like, for example, .saturating_add() instead of a simple +.

But in any case, corruption either hints at a compiler bug or the stack growing too far and corrupting the static data. As you do have quite a large amount of static data (2610 bytes debug/1800 bytes release), this is quite possible.

You may want to take a look at the contents of all that static data and where it came from - possibly you can get rid of a lot of it.

[hankertrix]

I see, I am currently using the build profiles that you mentioned as I used avr-hal-template to create my project.

I'm not sure what more I can do currently, as I have changed all integer operations to use the checked version, i.e. checked_add, checked_sub, checked_mul and checked_div. I can't use these for floating point values though, which I do use a lot of to calculate the acceleration for the stepper motor.

I think it is most likely the latter, but in my case, it isn't the static data that is being corrupted, as the objects representing the movement motors are initialised in the main function instead of being static variables, and they are stored inside a heapless::Vec. May I know what static data pertains to? I would guess variables that are declared as const or static, but are there any other variables I should be looking out for?

I have two heapless::String buffers which have a length of 512, which may be contributing to a lot of the static data, but I'm not sure either as the buffer is stored in a Mutex that starts with the None value.

Do you know of any way to print out the stack size at runtime? Like for example this function in Arduino C++:

static inline size_t stack_size()
{
    return RAMEND - SP;
}

[Rahix]

Unfortunately, we don't currently provide a function for easy access to the stack size. I created an issue to track this feature, as I agree that it would be very useful: Rahix/avr-device#175

[hankertrix]

That would be awesome!

Looking forward to the feature!

[Rahix]

and for completeness:

would guess variables that are declared as const or static, but are there any other variables I should be looking out for?

Yeah, const or static variables end up as static data with fixed addresses in SRAM.

I have two heapless::String buffers which have a length of 512, which may be contributing to a lot of the static data, but I'm not sure either as the buffer is stored in a Mutex that starts with the None value.

Even as a None value, these variables will take up the same amount of space as the Some value, so slightly more than 512 bytes in your case.

I can't use these for floating point values though, which I do use a lot of to calculate the acceleration for the stepper motor.

Keep in mind that on AVR floating point types are implemented purely in software. This means that a) calculations are much slower than integer operations and b) additional stack space will be occupied by the soft-float functions when calling them. General rule of thumb: Don't use floating point types on AVR.

[hankertrix]

I see, thanks for the answer and advice!

[djdisodo]

a bit late but you can open the compiled binary on IDA Pro and it will reveal what variable is taking up space, idk if there's free alternative

in my case i just never use debug build

[hankertrix]

I see, thanks.

[Rahix]

For static data, you can use nm and objdump to find the largest symbols:

Find largest static symbols

avr-nm "target/avr-atmega328p/debug/<filename>.elf" --size-sort | grep -vi ' t '

Dump contents of static symbols (only valuable for .data)

avr-objdump -d "target/avr-atmega328p/debug/<filename>.elf" -j .data -j .bss

[hankertrix]

Thank you!