• Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 475 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.

DSPLink: MEM_free() problem during shutdown.

Arya Ba
Intellectual 690 points
Other Parts Discussed in Thread: OMAP-L138

I will start out by an overview of our DSPLink setup. Initially, our setup consisted of a single POOL and two tasks/MSGQs on the ARM and DSP side, one with a lower priority than the other. Recently, we decided to add in a third DSPLink task and MSGQ pair. Now there are three local ARM and DSP MSGQ, managed by low, medium and high priority tasks. We followed the same procedure in adding the second task for the new third task and everything ran perfectly. However, upon shutting down ( we kill the tasks from lowest to highest priority ) the lowest priority task would terminate, but it would lockup the medium priority task.

Once we signal the lower task to shutdown, it executes its own TSKMESSAGE_delete (TSKMESSAGE_TransferInfo * info), and MSGQ_close() closes the proper MSGQ. The problem arises when we execute the MEM_free() to free the info structure ( line shown below ). Upon freeing the lowest priority TSKMESSAGE_TransferInfo, the medium priority task dies abruptly on the DSP side and locks up on the following line on the ARM side: MSGQ_get (SampleGppMsgqMed, WAIT_FOREVER, &msg).

Now, if we comment out the MEM_free() call ONLY from the lowest priority task everything shutdown properly without any hiccups. We conducted some memory tests and the MEM_free call is pointing to the proper info structure. Why does freeing the lowest priority task TSKMESSAGE_TransferInfo structure lockup/kill the medium priority task? If anyone could shed some light this we would highly appreciate it.

MEM_free (DSPLINK_SEGID,info,sizeof (TSKMESSAGE_TransferInfo)) ;

Note: We are using BIOS 5.33.05 / DSPLink 1.65.00.03 on the OMAP-L138 with Linux on the ARM Core.

 

Thank you very much,

Arya B.

 

  • TI__Expert 6860 points

    I'm not sure what's contained in your TSKMESSAGE_TransferInfo structure.  If its based off of the DSPLink's message sample application, it contains a pointer to both a locally opened and remote located MSGQ_Queue object.  You mention above that MSGQ_close is call on the the locally opened MSGQ in that Tsk.  I suspect that your medium priority Tsk is waiting (MSGQ_get) for the message that was deleted by the lower priority Tsk.  That's the reason why your application is hanging.

  • in reply to Arnie Reynoso
    Intellectual 690 points

    Hi Arnie,

    Thank you very much for the rapid reply, a picture is worth a thousand words, so to clarify somethings  I have depicted our setup bellow. Since I did not want to copy and paste, replace "X" with LO,MED, and HI for our three tasks. As you can see, each task only works on its own MSGQ pair, therefore, killing the LO priority task is an isolated event and should not effect the MED and HI priority tasks.

    To restate the problem, Once we send the shutdown signal to the LO priority task on the ARM, it is sent to the DSP where it switches to the deletion phase. Now, during that phase if we just release and close the MSGQ's everything will be fine. However, if we MEM_free(TSKMESSAGE_TransferInfo_LO), it causes the MED Priority task on the ARM to block on its own MSGQ_get ( MSGQ_MED_LOCAL ) . Lastly, I have checked the MSGQ Handles in each TSKMESSAGE_TransferInfo and they are all pointing to the proper MSGQs. One thing to keep in mind is that closing the MSGQ does not cause any problems it is just when we Free the TSKMESSAGE_TransferInfo structure which is really puzzling. 

    Thank you very much,

    Arya B.

  • in reply to Arya Ba
    TI__Expert 6860 points

    Based on your picture, I'm not sure what is going on here.  I agree that the MEM_free call shouldn't be affecting the other Task's MSGQ.  The only thing that come to mind is some type of buffer overflow either within the SEGID used for the allocation of the TSKMESSAGE_TransferInfo or the POOL from where the MSGQ buffers are being allocated from.  It might be that they are next to each other and one is stomping on the other.

    I have a few questions as I'm trying to get a better picture of the DSP-side application flow particularly when the TSKMESSAGE_TransferInfo is freed.   In what context (Tsk) are you freeing the TSKMESSAGE_TransferInfo structure?  Once freed, how is your application getting back to your medium priority Tsk?  Is the medium priority MSGQ already pending (waiting) on a message before the TSKMESSAGE_TransferInfo is freed?

  • in reply to Arnie Reynoso
    Intellectual 690 points

    Hi Arnie,

    Sorry for the delayed response, I will have to investigate the buffer over-follow; we wanted to verify all critical components before conducting a thorough memory analysis. The SEGID being used for the allocation of the TSKMESSAGE_TransferInfo_X is in a completely different memory location than the MSGQ_POOL and MSGQ buffers.

    To answer your question, both the DSP/ARM tasks run on start-up and are pending for data to arrive. On the DSP side, ideally, every TSKMESSAGE_TransferInfo_X is freed by the task that was using it. Therefore, TSKMESSAGE_TransferInfo_Low is freed by the low priority task and so on. Once the delete phase is completed, the task is terminated and returned to the operating system. This should leave the Medium and High priority tasks unaltered and pending on a message. Unless we are shutting down, in which case all task will be terminated from Low-Highest priority. 

     

    Thank you, 

    Arya B.