Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Malloc problem #863

Open
FroggyCorp opened this issue Jun 3, 2024 · 2 comments
Open

Malloc problem #863

FroggyCorp opened this issue Jun 3, 2024 · 2 comments
Labels
Critical Serious issue requiring priority fix help wanted mystery Mysterious issue not yet known to be bug, complication or other.

Comments

@FroggyCorp
Copy link

FroggyCorp commented Jun 3, 2024

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
Copy link
Owner

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 SpenceKonde added the mystery Mysterious issue not yet known to be bug, complication or other. label Sep 8, 2024
@SpenceKonde SpenceKonde added help wanted Critical Serious issue requiring priority fix labels Nov 1, 2024
@SpenceKonde
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Critical Serious issue requiring priority fix help wanted mystery Mysterious issue not yet known to be bug, complication or other.
Projects
None yet
Development

No branches or pull requests

2 participants