Synchronization problem in message queue mechanism

[Sebastian Huber]

Hello,

for a test case please have a look at the attached patch.  If I run this test 
on a simulator I get:

(gdb) b threadqprocesstimeout.c:42 if the_thread_queue == 0
Breakpoint 3 at 0x201da00: file 
../../../../../../rtems/c/src/../../cpukit/score/src/threadqprocesstimeout.c, 
line 42.
(gdb) r
Starting program: 
/scratch/git-rtems-testing/rtems/build-sparc-sis-rtems/sparc-rtems4.11/c/sis/testsuites/sptests/spintrcritical20/spintrcritical20.exe 



*** TEST INTERRUPT CRITICAL SECTION 20 ***

Support - rtems_timer_create - creating timer 1

Breakpoint 3, _Thread_queue_Process_timeout (the_thread=0x2046b00) at 
../../../../../../rtems/c/src/../../cpukit/score/src/threadqprocesstimeout.c:42
42        if ( the_thread_queue->sync_state != 
THREAD_BLOCKING_OPERATION_SYNCHRONIZED &&
(gdb) p the_thread_queue
$1 = (Thread_queue_Control *) 0x0

So we have a NULL pointer access in _Thread_queue_Process_timeout().  This 
destroys the system state.

On real systems the sequence in the test case can happen with nested interrupts 
which interrupt the clock tick handler (this is a common setup).

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-sptests-spintrcritical20-New-test.patch
Type: text/x-patch
Size: 7308 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20130822/745398e6/attachment.bin>