Synchronization problem in message queue mechanism

[Cezar Antohe]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130823/ffac3e9d/attachment.html>