Synchronization problem in message queue mechanism

[Gedare Bloom]

On Fri, Aug 23, 2013 at 4:24 AM, Cezar Antohe <antohecezar at yahoo.com> wrote:
>
> Hi,
>
> Thanks a lot for the posting, I think what you have simulated there is
> exactly one of our problem manifestations. Indeed, after that pointer is
> NULL in _Thread_queue_Process_timeout, the system state is invalid and
> probably other bad manifestations we've seen, start to appear.
>
https://www.rtems.org/bugzilla/show_bug.cgi?id=2140

Sebastian fixed the bug in 4.11 and for the next 4.10 release. You may
like to back-port to your working branch of 4.10 if you are not able
to update to a newer release of 4.10.

> One question, please, if it's ok with you - for a fast fix, what would you
> suggest, either verify that pointer for NULL and return immediately, if it's
> invalid, or wait for a fixing patch from you guys ?
> Or maybe disable interrupts altogether during the function call duration ?
> Would the NULL verification / interrupt disabling have negative impacts
> elsewhere ?
> Again, we are no experts in RTEMS, so sorry if my questions may not seem
> valid.
>
> Thanks a lot, cheers,
> Cezar
>
>
> ________________________________
> From: Sebastian Huber <sebastian.huber at embedded-brains.de>
> To: rtems-users at rtems.org
> Sent: Thursday, August 22, 2013 6:37 PM
>
> Subject: Re: Synchronization problem in message queue mechanism
>
> 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
>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>