Fatal exceptions on context-switching for more than two isolated threads

[Utkarsh Rai]

Hello, this thread has gone a bit cold over the last few weeks, due to my
engagement in the university tests.  I have provided a debug trace for the
issue.  The reason for fatal exceptions is the fact that while iterating
over the chain of user extensions we access a node whose memory location
has been set to NO-ACCESS during the context switch. Is there any
work-around to this?


On Tue, Sep 22, 2020 at 8:28 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:

>
>
>
> On Mon, Sep 21, 2020 at 10:29 PM Gedare Bloom <gedare at rtems.org> wrote:
>
>> On Sat, Sep 19, 2020 at 5:41 AM Utkarsh Rai <utkarsh.rai60 at gmail.com>
>> wrote:
>> >
>> > Hello,
>> > When I isolate more than two threads in RTEMS (the implementation can
>> be found here), I get fatal exceptions while context-switching. On stepping
>> into the code, the problem seems to be with the _User_extensions_Thread_*()
>> call  just after a context-switch, in particular when the iterators are
>> initialized inside this call. The issue is the fact that we mark the stack
>> space of the switched out thread as 'NO_ACESS' and then try to access
>> iterators(which belong to the stack space of the switched-out thread) from
>> a different thread, which leads to fatal exceptions.
>> > I am not sure how to handle this issue because I am not very clear on
>> the purpose of the "user extension" functionality or its implementation.
>> Any help would be appreciated, as this may possibly be the last hurdle for
>> a mergeable thread stack isolation feature.
>>
>> Are you testing in an SMP configuration? The user extensions in
>> uniprocessor run before the context switch.
>
>
> No, I am running with a simple uniprocessor configuration.
>
>
>> It would help if you
>> provide a trace of your debug.
>
>
> The backtrace -
>
> _Chain_Append_unprotected (the_chain=0x2002a0 <_User_extensions_List+12>,
>     the_node=0xfbf4fa0) at
> ../../../cpukit/include/rtems/score/chainimpl.h:694
> #1  0x0010d630 in _Chain_Iterator_initialize (
>     the_chain=0x200294 <_User_extensions_List>,
>     the_registry=0x2002a0 <_User_extensions_List+12>,
> the_iterator=0xfbf4fa0,
>     direction=CHAIN_ITERATOR_FORWARD)
>     at ../../../cpukit/include/rtems/score/chainimpl.h:1065
> #2  0x0010d92e in _User_extensions_Iterate (
>     arg=0x201df8 <_POSIX_Threads_Objects+2016>,
>     visitor=0x10d7f5 <_User_extensions_Thread_begin_visitor>,
>     direction=CHAIN_ITERATOR_FORWARD)
>     at ../../../cpukit/score/src/userextiterate.c:184
> #3  0x0010a172 in _User_extensions_Thread_begin (
>     executing=0x201df8 <_POSIX_Threads_Objects+2016>)
>     at ../../../cpukit/include/rtems/score/userextimpl.h:353
> #4  0x0010a21c in _Thread_Handler ()
>     at ../../../cpukit/score/src/threadhandler.c:140
> #5  0x0010e1e8 in _CPU_Context_switch_arm ()
>     at ../../../cpukit/score/cpu/arm/cpu_asm.S:121
>
>

The previous node of the chain was at 0xfbf7a0 which has been set to
NO-ACCESS during the context switch.


> You might consider using the event
>> recorder to also help with your debugging.
>> https://docs.rtems.org/branches/master/user/tracing/index.html
>
>
> Ok,  I will look into it.
>
>
>>
>>
>>
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201022/6c70088b/attachment.html>