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

Kernel
1

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
	#endif

} xQUEUE;

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.

cheers
Knut

2

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.

3

heinbali01 wrote on Thursday, May 25, 2017:

but it is entirely local to tasks.c

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

Cheers.

4

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…