<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 23, 2020 at 10:28 PM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 23, 2020 at 9:57 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>><br>
>> On 22/10/2020 02:40, Utkarsh Rai wrote:<br>
>><br>
>> > Hello, this thread has gone a bit cold over the last few weeks, due to<br>
>> > my engagement in the university tests.  I have provided a debug trace<br>
>> > for the issue.  The reason for fatal exceptions is the fact that while<br>
>> > iterating over the chain of user extensions we access a node whose<br>
>> > memory location has been set to NO-ACCESS during the context switch.<br>
>> > Is there any work-around to this?<br>
>><br>
>> The option is to move the User_extensions_Iterator storage out of the<br>
>> stack to Thread_Control and Per_CPU_Control.<br>
>><br>
><br>
> Does this mean that I should add User_extensions_Iterator field in the Thread_Control structure for the case<br>
> when we enable thread stack protection?<br>
><br>
<br>
You need to dig in a little bit more. From what I understand, there is<br>
the last_user_extensions_iterator field of the TCB. That is probably<br>
where you are running into some trouble. See<br>
score/src/userextiterate.c :193 where this field gets assigned to a<br>
stack-local variable. </blockquote><div><br></div><div>I get an exception just before this when _Chain_Iterator_initialize() is called, the reason though is the same, accessing </div><div>a stack-local variable of a switched out thread. From what I could understand,  the 'iter' variable(corresponding to the User_extensions_Iterator type)</div><div>is the only stack-local variable of a switched out thread that is accessed from a different thread.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Then, you can't walk this chain when the thread<br>
is out of context.<br>
<br>
>><br>
>> --<br>
>> Sebastian Huber, embedded brains GmbH<br>
>><br>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
>> Phone   : +49 89 189 47 41-16<br>
>> Fax     : +49 89 189 47 41-09<br>
>> E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>> PGP     : Public key available on request.<br>
>><br>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
>><br></blockquote></div></div></blockquote><div><br></div><div><br></div><div> Based on the above suggestions I tried to move the User_extensions_Iterator storage to the TCB by adding a new field to the structure, but that did not compile(userextimpl.h is not included with thread.h because of cyclic dependency).</div><div>This made me try out a naive hack, I defined a structure similar to the User_extensions_Iterator and then added the field to the TCB. The next problem that I faced was during the creation of the idle thread. Since an idle thread is created during system</div><div>initialization, the 'executing' pointer pointing the TCB is null, and hence referencing to the iterator placed in the TCB for the idle thread fails. This was resolved by separating the cases for an idle thread and other threads. After that I was able to successfully isolate more than two thread stacks.</div><div>Can you please suggest a more acceptable approach for resolving this issue?</div><div><br></div></div></div>
</div>