On Fri, Oct 23, 2020 at 9:57 PM Gedare Bloom <ged...@rtems.org> wrote:
> On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai <utkarsh.ra...@gmail.com> > wrote: > > > > > > > > On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> > >> On 22/10/2020 02:40, Utkarsh Rai wrote: > >> > >> > 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? > >> > >> The option is to move the User_extensions_Iterator storage out of the > >> stack to Thread_Control and Per_CPU_Control. > >> > > > > Does this mean that I should add User_extensions_Iterator field in the > Thread_Control structure for the case > > when we enable thread stack protection? > > > > You need to dig in a little bit more. From what I understand, there is > the last_user_extensions_iterator field of the TCB. That is probably > where you are running into some trouble. See > score/src/userextiterate.c :193 where this field gets assigned to a > stack-local variable. I get an exception just before this when _Chain_Iterator_initialize() is called, the reason though is the same, accessing a stack-local variable of a switched out thread. From what I could understand, the 'iter' variable(corresponding to the User_extensions_Iterator type) is the only stack-local variable of a switched out thread that is accessed from a different thread. > Then, you can't walk this chain when the thread > is out of context. > > >> > >> -- > >> 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.hu...@embedded-brains.de > >> PGP : Public key available on request. > >> > >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
