• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1334 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Heap Track, Orphan Tasks, and how do i figure this out?

cobsonchael
Mastermind 7930 points
Other Parts Discussed in Thread: SYSBIOS

Ok, so we have a fairly large project.  we are using

SYSBIOS 6.34.4.22

XDC tools 3.24.5.48

IP 1.25.1.09

in addition to that we have the SD card drivers running from the PSP examples.  this means i have

PSP drivers 3.0.1.00

EDMA3 2.11.6.1

we also have the NDK 2.22.0.06  running

and we are running on our own custom board with a 6748 DSP and our own platform file. all of this is running in CCSv5.2 with code gen tools 7.3.9

with that out of the way

we seem to have a heap problem. i turned on heap tracker and i am finding some heap sections that seem to be blowing their boundries.  sometimes it is the "boot" task and sometimes (most times) it is coming from the "orphan" task.  

for starters: What is the Boot task? What is the Orphan task?

How do i find who spawned an orphan task if no address is presented to show where the task lives? is the orphan task just 1 task or can it consist of multiple tasks that are all considered "orphans"

  • 0
    TI__Guru* 96960 points

    "boot" means the block was allocated in main() (or before main()). Note: the clockTick is always 0 for these blocks since the SYS/BIOS clock has not started yet.

    "orphan" means the (non-NULL) taskHandle that was assigned to the block when it was allocated is no longer present in the system. So if you have Task A, B, and C all alloc some memory (let's call them BlockA, BlockB and BlockC respectively), and Task A and B terminate (called Task_exit or exited the function), BlockA and BlockB will be "orphan" in the "TaskAllocList" page.

    Note: not all orphans are memory leaks. For instance, the NDK BootTask allocates memory for the networking stack and then terminates. It shows up as orphan blocks even though they are definitely in use and not leaks.

    It looks like we should put the taskHandle in the "TaskAllocList" page also to let you know the orphaned task. However, you can cross-reference the blockAddr in the orphan list with the blockAddr in the "HeapAllocList" to get the taskHandle.

    Todd

  • 0 in reply to ToddMullanix
    Mastermind 7930 points

    ok so the "boot" task is one that is created in main OR do you mean there was a malloc in main and the heap tracker just labels that as "boot"?

    what i am observing is that the boot task doesn't allocate any memory until after sysbios starts so i still don't understand this boot task section.

    the orphan tasks are tasks that have terminated and thus are no longer running.  therefore the heap sections in the orphan tasks are lost memory, they are allocated memory that was never free'd before the task exited, correct? orphan tasks do not run and never can run again, right?

    so if i am getting a heap section overrun in the orphan task...that is still a bad thing because as far as the heap is concerned that memory is being used by someone and nothing should be writing in that memory section.

  • 0 in reply to cobsonchael
    TI__Guru* 96960 points

    "boot" means the memory block was allocated in main() (or before main()). How did you determine that memory was allocated by "boot" after SYS/BIOS starts (e.g. did you have a breakpoint at BIOS_start and you looked at ROV)?

    Memory is not "owned" by the task that allocated it. So when a task terminates it is not necessarily a memory leak if that task does not free all the memory it allocated.

    As I mentioned, the NDK boot task (not to be confused with "boot" in HeapTrack) creates the NDK stack task (among other things) and a terminates. Within the Task_create, memory is allocated and HeapTrack denotes the NDK boot task as the allocator of the memory. When the NDK boot task terminates, it does not free that memory because the memory is being used by the NDK stack task.

    Todd 

     

     

  • 0 in reply to ToddMullanix
    Mastermind 7930 points

    well when i boot my machine and i drop into sysbios i halt and look at the ROV after it was running for about a minute and the boot task has no memory allocated. later when i do something (still trying to figure out what that something is) the boot task then has some memory allocated to it. this is why i can't understand how boot can get any memory unless the BIOS_START generates a boot task.

    so i guess i have to find out who allocates this memory and i have to find out if whoever inherits this memory is blowing the section or something else is.

  • 0 in reply to cobsonchael
    Mastermind 7930 points

    ,1931,0xac6eac6e,0xc3500b40,0x158a3260,0xac6eac6e,2892934254,YES

    the above information is what i get for the heap allocation list.  it would appear that the location of this heap section is completely blown away with data 0xac6e repeated so i cannot find the task that this belongs to.

    would it be the previous or the next heap section in the list i should be looking at for the culprit (assuming that another heap section is what is killing this one)

  • 0 in reply to cobsonchael
    TI__Guru* 96960 points

    HeapTrack stores the task information, scribble byte, clocktick, etc. at the end of the allocated block (putting it at the front would impact alignment). Sounds like you allocated a block of size N and then wrote past the Nth byte. Or you could have a bad pointer and randomly wrote in this location. i expect the former is more likely.

    Todd

  • 0 in reply to ToddMullanix
    Mastermind 7930 points

    thanks i think we figured out he culprit. unfortunately it is occurring with a 3rd party routine and we have to wait for them to fix it.