[Bug 2068] New: pthread_create race condition (task_start userext executed after thread is already running)

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=2068

             Bug #: 2068
           Summary: pthread_create race condition (task_start userext
                    executed after thread is already running)
    Classification: Unclassified
           Product: RTEMS
           Version: 4.9
          Platform: All
        OS/Version: RTEMS
            Status: NEW
          Severity: critical
          Priority: P3
         Component: cpukit
        AssignedTo: joel.sherrill at oarcorp.com
        ReportedBy: strauman at slac.stanford.edu


I observe pretty reproducable crashes when using pthreads under rtems-4.9.
(bug *still* present on current 'master' branch as of 2012/6/12) when
using 'capture' at the same time.

It seems that a function running in a new pthread context finds '0xdeaddead'
on the stack upon returning to its caller and jumps into the wild.

Apparently, the capture engine overwrites the task's stack with 0xdeaddead
*after* the task is already running.

I believe that 'pthread_create()' is the culprit. It creates a SCORE thread
and then calls

_Thread_Start( )

*without* disabling thread-dispatching.

However, _Thread_Start() marks the thread as 'runnable' *before* calling
user extensions (_Thread_Start() body):

{
    if ( _States_Is_dormant( the_thread->current_state ) ) {

      the_thread->Start.entry_point      = (Thread_Entry) entry_point;

      the_thread->Start.prototype        = the_prototype;
      the_thread->Start.pointer_argument = pointer_argument;
      the_thread->Start.numeric_argument = numeric_argument;

      _Thread_Load_environment( the_thread );

      _Thread_Ready( the_thread );

      _User_extensions_Thread_start( the_thread );

      return true;
    }

    return false;
}

Therefore, could it not be that the thread is already scheduled *before*
user extensions are executed? In this scenario, the following race condition
could occur:

1. thread X calls pthread_create
2. _Thread_Start() marks new thread Y 'ready'
3. 'Y' is scheduled, calls stuff and blocks
4. 'X' runs again and executes user extensions for 'Y'
5. capture engine's 'thread_start' extension fills 'Y's stack with
0xdeaddead
6. 'Y' is scheduled again, when popping a return address from the stack
     it jumps to 0xdeaddead and crashes the system.

NOTES:
   - other APIs (rtems, itron) *have* thread-dispatching disabled around
_Thread_Start()
   - the current 'master' branch seems to still suffer from this
   - has nothing to do with 'capture' per-se *any* user extension is possibly
     affected. It is a bug in pthread_create()
   - I consider this a serious bug.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.