BUG? stack corruption in posix thread.

[Till Straumann]

On 06/12/2012 03:47 PM, Joel Sherrill wrote:
> I agree with your analysis. Dispatching should be disabled
> once all resources are allocated and before _Thread_Start
> is called.
>
> But is it the capture thread or stack overflow checker
> that is writing the pattern?
It is the rtems_capture_start_task() extension callback
which fills the stack with 0xdeaddead when a task is started.
>
> I assume you have a patch for this and it is helping?
I haven't tried yet. Mostly because I was unsure
if the critical section in pthreadcreate.c should include
  _Watchdog_Insert_ticks() or if that is not necessary.

- T.
>
> On 06/12/2012 03:39 PM, Till Straumann wrote:
>> I observe pretty reproducable crashes when using pthreads under rtems-4.9.
>>
>> 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 ) )
>> {../../score/src/apimutexunlock.c
>>
>>        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
>>     - I consider this a serious bug.
>>
>> -- Till
>