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

**URL:** <https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902>\
**Category:** Kernel\
**Created:** [December 14, 2017, 5:51pm UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902 "2017-12-14T17:51:49Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 14, 2017, 5:51pm UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902/1 "2017-12-14T17:51:49Z")

</div>

**[abhi29091996](https://sourceforge.net/u/abhi29091996/)** wrote on [Thursday, December 14, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e6df96a4/#222d):

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.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [December 14, 2017, 7:55pm UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902/2 "2017-12-14T19:55:11Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Thursday, December 14, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e6df96a4/#222d/b9a0):

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.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 15, 2017, 4:10am UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902/3 "2017-12-15T04:10:36Z")

</div>

**[abhi29091996](https://sourceforge.net/u/abhi29091996/)** wrote on [Friday, December 15, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e6df96a4/#0c49):

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.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [December 15, 2017, 4:18pm UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902/4 "2017-12-15T16:18:22Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, December 15, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e6df96a4/#0c49/2d44):

> 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?

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 15, 2017, 7:02pm UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902/5 "2017-12-15T19:02:14Z")

</div>

**[abhi29091996](https://sourceforge.net/u/abhi29091996/)** wrote on [Friday, December 15, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e6df96a4/#485b):

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.

---

<div class="post-metadata">

**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\
**Post date:** [December 16, 2017, 6:44am UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902/6 "2017-12-16T06:44:00Z")

</div>

**[heinbali01](https://sourceforge.net/u/heinbali01/)** wrote on [Saturday, December 16, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e6df96a4/#fdf1):

> 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](https://www.freertos.org/Stacks-and-stack-overflow-checking.html)
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()`](https://www.freertos.org/a00111.html)
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

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 16, 2017, 3:26pm UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902/7 "2017-12-16T15:26:40Z")

</div>

**[abhi29091996](https://sourceforge.net/u/abhi29091996/)** wrote on [Saturday, December 16, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e6df96a4/#1249):

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.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [December 16, 2017, 5:11pm UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902/8 "2017-12-16T17:11:31Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, December 16, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e6df96a4/#1249/6f56):

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.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 16, 2017, 5:55pm UTC](https://forums.freertos.org/t/assert-in-xqueuegenericreceive-function-of-queue-c-file-of-freertos-v9-0-0/6902/9 "2017-12-16T17:55:34Z")

</div>

**[abhi29091996](https://sourceforge.net/u/abhi29091996/)** wrote on [Saturday, December 16, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e6df96a4/#a62b):

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