Malloc problem

[FroggyCorp]

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)
- ((int)&__data_end - (int)&__data_start)
- ((int)&__bss_end - (int)&__data_end)
- ((int) (__brkval == 0 ? (uint8_t *) &__heap_start : __brkval) - (int)&__bss_end)
- (RAMEND - (int)SP + 1);
pinMode(1, OUTPUT);

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]

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]

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

[FroggyCorp]

Hi,
Sorry for the delay(0xFFFFFFF(UL)), i didn't see your reply (or forget it :]). I think with some debugger, it could be easy to find the bug, from my code or yours or attiny or gods. But i still need my kidney ;)
If i'm the only one who get that problem, it should go to hell. As you said, malloc is not common use under AVR, specialy with 512b of memory. In my case it was to create the array for transmission above air which could be 256 byte maximum. I can save 256byte for transmission during that part of the process.
In reality, it don't really make sens, because that size of packet should never happen, but for some simplicity in my code, it was more easy to use malloc for generic packet than using some #define everywhere depending on which uC i'm using.
Regards,
Despite that problem, you make great work :)