adlerweb
commented
6 years ago Aaaand since I rediscovered the bug today let's get a bit deeper:
My plan was to store module specific configuration in an array. Since the number ob configurations can change and RAM is somewhat limited the plan was to free() on detach, recount the required number of configured items in EEPROM and malloc/calloc the needed space to hold everything in RAM. Using EEPROM directly did show massive delays when processing packages and I would like to avoid waiting seconds for my light to turn on. While using malloc/calloc is usually a bad idea when dealing with µCs (I like bad ideas), I thougt it would still work out since the blocks used are fairly large and only allocated when changing the modules configuration. Obviously I was wrong.
According to the documentation calloc/malloc would do some internal voodoo to aviod fuckups and return NULL if memory could not be allocated due to lack of memory or other problems. This was somewhat dealt with by aborting configuration in such a case. Looks like this doesn't coincide with the controllers actual behaviour - instead of returning NULL calling calloc (or malloc) during reconfiguration causes the AVR to completely hang and never return.
I don't think it's due to lack of memory - heap contains only a single config at this point, can hold much more when not reloading, and stack shouldn't be filled that much at this point. Also the usual memory-free-functions do not indicate a lack of memory.
tl;dr: malloc/free seems to be not only "not recommended" but more like broken on AVR. Goto 1 and think about another way of storing the configuration.
TIL: Setting NULL where something should be NULL might help. In the end just a simple double free.
When using attach on DOut or DIn the configuration reload (Detach/Attach) will hang if more than two inputs/outputs are used