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.ra...@gmail.com> wrote: > > > > On Mon, Sep 21, 2020 at 10:29 PM Gedare Bloom <ged...@rtems.org> wrote: > >> On Sat, Sep 19, 2020 at 5:41 AM Utkarsh Rai <utkarsh.ra...@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@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel