SpenceKonde / ATTinyCore

Arduino core for ATtiny 1634, 828, x313, x4, x41, x5, x61, x7 and x8
Other
1.6k stars 311 forks source link

Malloc problem #863

Open FroggyCorp opened 5 months ago

FroggyCorp commented 5 months ago

Hi,

I have some no sense issue on malloc and i have no way to reproduce it with simple code. I have some program using malloc which work on nano/STM32 but not on a Attiny85 with 2 malloc during the setup(). The attiny reboot during the malloc BUT if i add some testing around malloc, the attiny don't reboot and the program work ? I checked some memory leak (at setup() ?) with oscillo with that kind of code :

` int available = (RAMEND - (int)&__data_start + 1)

digitalWrite(1, LOW);

delay(100); digitalWrite(1, HIGH); delay(free_memory) digitalWrite(1, LOW); ` before and after the malloc, and i get enought memory (~300B) and the malloc take the correct amount of memory. The only fact to add that digitalWrite, make the program work. It could be delay issue, but i don't know.

So i changed all malloc by static allocation and no more problem.

Regards,

SpenceKonde commented 2 months ago

I think the solution you have come to - switching to static allocation - is the correct one. Using malloc on an AVR is generally inadvisable, and that applies especially to tinyAVRs with notably small memories, the overhead is rather dreadful, the benefits dubious, and the event that a malloc fails is generally handled by proceeding blindly ahead straight into the gaping hole in their path (I've seen code that, if malloc failed, would cheerfully begin scribbling over the special function registers located at 0x0000 - but what do you expect, I maintain a core, so I'm exposed to code from users that I'm convinced could free the world from fossil fuel* . That said, provided sufficient memory is available, it really should work.

I have sometimes, in extremely simple programs, experienced loss of basic functionality which disappears upon addition of any sort of probing. I thought I had worked around that, in main.cpp, I think comment mentions voodoo, and it makes no sense that doing that there should fix it. But it did in my test case.

I still don't understand it, it's a matter of concern if my voodoo trap isn't working right.

*it requires embedded developers in coffins that can rotate, driving an electric generator as they roll over in their grave, .

SpenceKonde commented 2 weeks ago

I have no further understanding of the cause, but on second read it is abundantly obvious that this is a CRITICAL bug,