Local Building - does not compile with warnings?

Thanks

@peekay123, Do you know what files I would have to edit in the develop branch to change mallocr to malloc? Just so I can start testing my code I cant really wait a week or 2.

@wesner0019, nope. I am waiting for Mat also :disappointed:

@peekay123, do you think this would work from BKO from MDMA?

"
Hi @wesner0019

here are @mdmaā€™s instructions for tracking down your linker problem:

Hereā€™s how to find out which function is causing the problem:

add a function extern ā€œCā€ void* _sbrk() { return NULL; } to your
program. This is only temporary and will fill in the missing function so
the code links.open the user-part.lst file that is produced alongside your compiled application codesearch for sbrk to find which function is calling that. (Itā€™s usually _mallocr)then search for mallocr and see which function is calling that. That will tell you which function is trying to allocate memory directly via mallocr rather than via malloc()
"

@wesner0019, the _sbrk source is well known to be in the Time class. The Time functions call malloc_r() instead of malloc(). If you donā€™t use any Time functions then you wonā€™t get the error. In my case, I am using Time so I will want Mat to fix this correctly.

@peekay123, thanks, after a quick search I quickly realized I had no idea what I was even looking for. :expressionless: guess Iā€™ll hurry up and wait.

1 Like

Just git pulled today on the latest branch and found that the sbrk bug now afflicting the latest branch today as well, but only for photon, not core. Strange.

@bpr, latest is actually 0.4.4rc2 which has inherited the _sbrk issue. If you clone photon_043 that will get you the 0.4.3 working version. :smile:

@peekay123, Ah that explains the photon/core disparity. Thanks!

1 Like

The _sbrk() linker error has been fixed and will be rolled out to the IDE later this week, if all goes to plan! :smile:

Where is the source code for malloc() located? Canā€™t seem to find it in github firmware. I assume it is calling _sbrk() which does raw allocation from the heap. _sbrk() does not take care of the malloc() linked list and block size information.

Iā€™m confused over the return I am getting from _sbrk(0) in v0.4.4. I am getting a 0xffffffff return each time. This should return what is the address of the top of the heap looking at src/newline_stubs.cpp. Is the function changed in v0.4.4? I am calling malloc() every second in the test application and never releasing memory. So I expected _sbrk(0) to return increasing memory addresses over time as more of the heap is allocated. But it was pegged at 0xffffffff.

Malloc() allocation seems interesting. I had a test application doing a malloc(16) in each loop(). It appears malloc() allocates a bigger chunk than it needs and divides it up as new malloc() calls arrive that can be serviced out of that chunk, before allocating a new chunk. The return addresses go up as each chunk is allocated, but lower addresses are returned are parts of the allocated chunk are allocated. Malloc() appears to allocate from the top of one of these chunks down.

malloc() is part of the C runtime library, so youā€™ll need to hunt for the gnu compiler sources.

_sbrk() isnā€™t linked to the system module so I doubt youā€™ll get anything useful. (Surprising you donā€™t get a linker error.) You can add it as a system module export by adding it to the end of the list in rt-dynalib/inc/rt_dynalib.h and rebuild/flash system firmware, and rebuild your application. Then it will work as expected.