Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

abhi29091996 wrote on Thursday, December 14, 2017:

In Our Project Host Controller(LPC4320) is ASSERTING at line no 1245 of “queue.c” file.There is “configASSERT( !( ( pvBuffer == NULL ) && ( pxQueue->uxItemSize != ( UBaseType_t ) 0U ) );” function written over there.I really don’t understand the condition written over there.We have guaranteed that pvBuffer isn’t equal to NULL,so it won’t ASSERT at the same line.Issue nature is Random.
Another confusion is that imagine a scenario in which pxQueue->uxItemSize is 0 but,pcBuffer isn’t equal to NULL.
Project details are confidential but,let me know if more details required for this.

rtel wrote on Thursday, December 14, 2017:

The line is checking you do not try to write received data to a NULL
pointer. pvBuffer can be NULL if uxItemSize is 0 because no bytes are
written. You can work out a truth table for the inputs, it will only
have four rows, the only output that is 0 (and therefore cause the
assert to trigger) should be the row where

( ( pvBuffer == NULL ) && ( uxItemSize != 0 ) )

If you don’t think that is the case then please post the truth table
here so we can see (I have done it myself before posting).

If the assert is really failing then you are violating the inputs. You
can turn asserts off, but then your program will just crash when you try
to write to NULL.

abhi29091996 wrote on Friday, December 15, 2017:

Lets Say (pvBuffer==NULL)=Condition1 and (uxItemSize!=0)=Condition2 and Output.

Condition1 Condition2 Output Assert
False False False No
False True False No
True False False No
True True True Yes

According to this truth table i am sure that pvBuffer is passing as NULL Right?
Again we have dig to this issue and found that program is calling to xSemaphoreTake(line 248 semphr.h) where pvBuffer is passed as NULL.But there is some data in queue.

rtel wrote on Friday, December 15, 2017:

Condition1 Condition2 Output Assert
False False False No
False True False No
True False False No
True True True Yes

So your finding is that the assert only occurs if pvBuffer is NULL, but
uxItemSize is not zero, which (without the assert) would result in
received data being copied to a NULL pointer, hence the assert is correct.

Again we have dig to this issue and found that program is calling to
xSemaphoreTake(line 248 semphr.h) where pvBuffer is passed as NULL.But
there is some data in queue.

If this is a semaphore then the assert is from an internal call where
pvBuffer should be NULL and uxItemSize should be 0 as that is the case
for all semaphores. If the assert is being hit then my guess is you
have a data corruption somewhere - maybe the semaphore’s data structure
has been overwritten so uxItemSize is not 0?

abhi29091996 wrote on Friday, December 15, 2017:

As said above that semaphore structure is corrupted and uxitemsize is not 0.I have done my full analysis on this issue and issue is same as said above “data corruption”.But can you please tell more on this kind of data corruption.I mean full explaination of data corruption.

heinbali01 wrote on Saturday, December 16, 2017:

I mean full explaination of data corruption.

I’m afraid that is a task for you to do.

I do have a few hints though, mistakes that most of us have ever made:

  1. A task is running out of it stack space
  2. An array is written to outside its bounds, e.g. passing bad length to memcpy() or memset()
  3. Forget to check the result of pvPortMalloc()
  4. Some functions in your application try to use malloc() in stead of pvPortMalloc()
  5. Call non-re-entrant functions from different tasks
  6. Access objects from different tasks while those objects are not thread-safe and need a mutex
  7. Use of automatic variables (on stack) and forget to initialise them

Issue nature is Random.

That is a typical sign of data corruption

abhi29091996 wrote on Saturday, December 16, 2017:

Sorry for trouble but got to know somemore reason.I will look into my sourcecode for this kind of possiblity.
There is problem that i have to provide solution in my next release immediately so time is less for analysis.Can you provide some suggession to solve this problem.

rtel wrote on Saturday, December 16, 2017:

Put as simply as possible, something in your code is writing over RAM it
is not supposed to be writing over. That is the symptom - Hein has
provided a list of possible causes - but you are the only one with the
code so only you can judge where that might happen.

abhi29091996 wrote on Saturday, December 16, 2017:

Very fast reply.Thanks for your efforts and i will look for it in code.