CW10.6+MQX4.1.1+CPLUS example question about lwmem and task_abort

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CW10.6+MQX4.1.1+CPLUS example question about lwmem and task_abort

Jump to solution
637 Views
DavidS
NXP Employee
NXP Employee

Hello,

I'm using the MQX.4.1.1/mqx/examples/cplus as a test vehicle.

I have modified it to simulate a task being aborted to test if the heap allocations for the task are freed.

Here is the only modification to the cplus.cpp file:

void cplus_task

   (

      uint32_t initial_data

   )

{

   { // Scope for local to destruct

      HelloWorld local;

      HelloWorld *heap;

      global.print("global");

      local.print("local");

      heap = new HelloWorld;

      if (heap != 0) {

         heap->print("heap");

#if 1 //DES 1=test, 0=default code

         goto abort_now;

#else

         delete heap;

#endif

      } else {

         _io_printf("heap: new failed\n");

      } /* Endif */

   } // local should destruct

   _io_fflush(stdout);

#if 1 //DES 1=test, 0=default code

abort_now:  

   _task_abort(_task_get_id());

#else

   _task_block();

#endif

}

The stack, variables and code step are shown:

ScreenHunter_88 Dec. 16 15.22.gif

The MQX Light Memory Pools has the Owner as System with Type 0x1fff:

ScreenHunter_89 Dec. 16 15.23.gif

It seems that for the lwmem alloc process which first jumps into a C++ library before returning to MQX to allocate memory but the block_ptr->U.S.TASK_NUMBER in lwmem.c  is set to 0xffff rather than 0x0003.  When the _task_abort() runs, the heap does not free the heap space that is allocated during the "heap = new HelloWorld;" code. 

ScreenHunter_90 Dec. 16 15.28.gif

If I "hack" the lwmem alloc so the block_ptr->U.S.TASK_NUMBER is 0x0003, the Heap Owner is task 0x10003 and the heap frees correctly when _task_abort() runs.

ScreenHunter_91 Dec. 16 15.30.gif

ScreenHunter_92 Dec. 16 15.30.gif

Is this a C++ issue?

Regards,

David

0 Kudos
1 Solution
359 Views
matus_marinak
NXP Employee
NXP Employee

Not an issue.

In current MQX C++ implementation user in this case need to call delete on all allocated objects in task as in standard C++.

This solve memory leaks.

If user want's to avoid of using deallocation of created objects, he can try to change in file comp.c malloc function change call from _mem_alloc_system() to _mem_alloc(). Then all allocated objects in task will be assigned to parent task.

View solution in original post

0 Kudos
2 Replies
360 Views
matus_marinak
NXP Employee
NXP Employee

Not an issue.

In current MQX C++ implementation user in this case need to call delete on all allocated objects in task as in standard C++.

This solve memory leaks.

If user want's to avoid of using deallocation of created objects, he can try to change in file comp.c malloc function change call from _mem_alloc_system() to _mem_alloc(). Then all allocated objects in task will be assigned to parent task.

0 Kudos
359 Views
DavidS
NXP Employee
NXP Employee

Thank you Matus for your help and education.

Regards,

David

0 Kudos