Repeat "new delete" operator cause heap overflow

Mbed OS
,
1

i used to mbed 5.15 version.

when i repeat “new” and “delete” operator, occurs heap overflow.

class deleted but next new operator allocated the next address.

repeat. repeat. repeat…

next address over heap end address.

i want avoid this problem

help

2

do not use the heap :wink:

jokes aside, why do you need to new and delete so much? can you show your code?

3

this problem occurs when i delete old thread(needless) and create new thread.

i wanted to additional features, so i create a new thread.

but my code is out of memory.

so i thought deleting the deprecated threads and creating a new thread would solve the problem.

but new thread address does not enter an address previously deleted.

assign to next address. so, when creating use to ‘new’ operator, out of memory.

//////////////////////////////////////////

HOST *pgHost = new HOST();

HOST::HOST() : :
SerialPipe(HOST_TX, HOST_RX, 115200, gHostRxBuff, sizeof(gHostRxBuff), 0, gHostTxBuff, sizeof(gHostTxBuff)), _daemon(NULL)
{
pgHost->setDataMode();
pgHost->setReport(false);
_debug_trace_on = false;
mutex_init();
_daemon = new Thread(osPriorityNormal, OS_STACK_SIZE * 2, NULL, “host”);
_daemon->start(callback(this, &HOST::daemon));
setWdgFlag(etrHOST);
rmc_timestamp = 0;
}

////////////////////////////////

like the example above, i create a thread.

Delete unnecessary threads through ‘if’ operator, and then create new thread.

4

Hello Lee,

Ladislas is right, do not use the heap :wink: You can provide your own static memory using the constructor parameters. Try to define a global array of the desired size and pass it to the Thread’s constructor rather than the default NULL. After deleting the old thread you can use the same memory location (same array) to create a new one.

5

thank you for your answer, your answer is hard to understand.

My understanding is define thread array.

for example,

Thread[3];

Thread[0] = threadA;
Thread[1] = threadB;
Thread[2] = threadC;

and delete threadB, new threadD allocate to Thread[1].

Is my understanding correct?

6

your answer is hard to understand.

I’m sorry for that. In the example below three static arrays of bytes (threadStack0, threadStack1 and threadStack2) are allocated in order to be used as Thread stacks. Then a Thread daemon is created in the static memory (array of bytes) threadStack0. When the daemon is not needed anymore it is deleted and a new Thread myThread is created in the same static memory (array of bytes) threadStack0. The other two arrays (threadStack1 and threadStack2) are not utilized in this example (you can delete them to use less SRAM):

#include "mbed.h"

#define THREAD_STACK_SIZE   OS_STACK_SIZE * 2

DigitalOut  led1(LED1);
uint8_t     threadStack0[THREAD_STACK_SIZE];    // static memory to be used as thread stack
uint8_t     threadStack1[THREAD_STACK_SIZE];    // static memory to be used as thread stack
uint8_t     threadStack2[THREAD_STACK_SIZE];    // static memory to be used as thread stack
Thread*     daemon;
Thread*     myThread;

void taskDaemon()
{
    while (1) {
        printf("Task daemon\r\n");
        ThisThread::sleep_for(500ms);
    }
}

void taskMyThread()
{
    while (1) {
        printf("Task myThread\r\n");
        ThisThread::sleep_for(500ms);
    }
}

int main()
{
    int count = 0;

    daemon = new Thread(osPriorityNormal, THREAD_STACK_SIZE, threadStack0, "host"); // create a thread at threadStack0
    daemon->start(callback(taskDaemon));

    while (true) {
        led1 = !led1;
        ThisThread::sleep_for(500);
        count++;
        if (count == 10) {
            osStatus    status = daemon->terminate();
            if (status == osOK) {
                delete daemon;
                myThread = new Thread(osPriorityNormal, THREAD_STACK_SIZE, threadStack0, "my_thread");  // create a thread at threadStack0
                myThread->start(callback(taskMyThread));
            }
        }
    }
}

This thread could be useful too.

7

That’s a very nice example! Would you say it’s good practice to use static memory for thread instead of relying on the new operator when a thread is started?

Why * 2?

8

Would you say it’s good practice to use static memory for thread instead of relying on the new operator when a thread is started?

When creating automatic objects on the stack, the size of the objects and their lifetime is built into the generated code, because the compiler knows the exact type, quantity, and scope.
Creating objects on the heap is very useful when the number of objects and their lifetime can vary during the program execution. However, it involves additional overhead, both in time and in space.
The heap is searched for a block of memory large enough to satisfy the request. This is done by checking a map or directory of some sort that shows which blocks are currently in use and which are available. It’s a quick process, but it may take several tries so it might not be deterministic – that is, you cannot expect that it’s always taking exactly the same amount of time.
Of course, a more sophisticated new-handlers can be written, even one to try to reclaim memory (commonly known as a garbage collector).
So in my opinion, if the number of objects and their lifetime is known at design time it’s better to create them in the static memory.

Why * 2 ?

I just copied that from the Lee’s example code. I expect he is creating a lot of automatic variables on the thread’s stack and they do not fit into the default OS_STACK_SIZE.