wrong use of #defines in xQUEUE type, v9.0.0

odman wrote on Thursday, May 25, 2017:

In queue.c, 
typedef struct QueueDefinition
	#if ( configUSE_TRACE_FACILITY == 1 )
		UBaseType_t uxQueueNumber;
		uint8_t ucQueueType;   //<-- Line 162


In xQueueGenericReceive(), line 1279
					#if ( configUSE_MUTEXES == 1 )
						if( pxQueue->uxQueueType == queueQUEUE_IS_MUTEX )
In my FreeRTOSConfig.h:
#define configUSE_MUTEXES                         ( 1 )
#define configUSE_TRACE_FACILITY                  ( 0 )

I’m not sure how this even compiles, but it does with GNU ARM 4.9.3. The result is that illegal memory is written with unpredictable consequences.


heinbali01 wrote on Thursday, May 25, 2017:

Please have a look at the large comment around line 97, and these defines :

#define pxMutexHolder					pcTail
#define uxQueueType						pcHead

In case a queue object is in fact a mutex, the two fields are not used in their normal way (head, tail). These are pointers, not characters. uxQueueType will be set to NULL (queueQUEUE_IS_MUTEX).

It may look a bit confusing, but it is entirely local to tasks.c. I’m sure it was done to save a few bytes of RAM.

In another C project a union could be used for this, but union's are not supported by all compilers that are used to compile the FreeRTOS kernel.

The member used when tracing: ucQueueType is indeed an 8-bit field that holds a copy of ‘ucQueueType’ that was used during creation.

In short: there is nothing wrong with it.

heinbali01 wrote on Thursday, May 25, 2017:

but it is entirely local to tasks.c

Sorry, not task.c but queue.c of course.


odman wrote on Thursday, May 25, 2017:

wow. Missed that. Thanks. The good news is that FreeRTOS works, the bad news is that something else is messing up my stack…