AnsweredAssumed Answered

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

Question asked by David E Seymour Employee on Dec 16, 2014
Latest reply on Mar 3, 2015 by David E Seymour

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

Outcomes