4 Replies Latest reply on Dec 23, 2013 4:36 PM by jasonrc

    Issue working with wiced_queue_t (ThreadX)

      Hi,

       

       

      Im seeing some issue with memory corruption or halting the system on following scenario

       

      1) Create message queue from application thread (start thread)

       

      2) push message queue from another thread (Say "Thread 2")

       

      3) pop message queue from another thread (Say "Thread 3")

       

       

      However, if I pop message from my application thread then it works great... message is still pushed by "Thread 2".

       

       

      Any ideas? is this ThreadX limitation of message queue between thread? I checked the ThreadX spec and i do not see such limitation...

        • 1. Re: Issue working with wiced_queue_t (ThreadX)
          Hi,

           

           

          Update to my original question/issue:

           

           

          I have found the issue (not confirmed) which is related to my new Thread stack size vs. the message queue size... My Thread stack size is 1024 and the message queue is around 600 bytes. If i reduce the message queue size to 200 byte or increase the Thread stack size to 2048 then the issue is resolved.

           

           

          However, this is strange because of following reason:

           

          1) Message queue is allocated from memory pool, not from local memory (stack).

           

          2) The Thread that is calling the wiced_rtos_pop_from_queue also allocates the message buffer container from memory pool (malloc). The Thread is simply and does not contain any recursive function calls... simply allocate the memory (one time) and calling wiced_rtos_pop_from_queue from while loop.

           

           

          PS. Maybe im wrong but i dont think queue pushing or popping will actually use the callings thread stack base on the message total size.... any ideas? feedback will be appreciated.
          • 2. Re: Issue working with wiced_queue_t (ThreadX)
            Can you provide the code you are using to init the queue and push & pop messages?

             

             

            The contents of the queue are allocated from the heap and pushing or popping from the queue involved a memcpy() of the message content to or from your local storage.

             

            Popping a message from a queue into a local variable that is too small will cause stack corruption but depending on the order of the variable declarations in the function the corruption may or may not be fatal.
            • 3. Re: Issue working with wiced_queue_t (ThreadX)
              Can you provide the code you are using to init the queue and push & pop messages?

               

               

              The contents of the queue are allocated from the heap and pushing or popping from the queue involved a memcpy() of the message content to or from your local storage.

               

              Popping a message from a queue into a local variable that is too small will cause stack corruption but depending on the order of the variable declarations in the function the corruption may or may not be fatal.

               

               

              Hi Nikvh,

               

               

              Just to clarify that my issue was resolved, the problem is printing logs in my thread with small stack size assigned.. it somehow corrupted my memory. So for anyone using log prints make sure your thread stack size is at least 4Kbyte (or larger).
              • 4. Re: Issue working with wiced_queue_t (ThreadX)
                Thanks for letting us know.

                 

                There is a note in <WICED-SDK>/include/wiced_defaults.h about stack requirements for printing.

                 

                The note is right above the #defines that control print levels. Copied below FYI ...

                 

                 

                /************************************************************************
                 * ** WARNING for PRINTING **
                 *  If printing is enabled, the stack of each thread that uses printing
                 *  must be increased to at least 4 kBytes since the printf function uses
                 *  a lot of memory (including dynamic memory)
                 */
                /************************************************************************