Synchronization problem in message queue mechanism

[Gedare Bloom]

This bug affects the head then too? Please commit the test case and
file a PR if there is not one associated with the bug.

On Thu, Aug 22, 2013 at 11:37 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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.
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>