Re: RTEMS big comment conventions
Hi Joel, > On 22 Oct 2020, at 17:13, Joel Sherrill wrote: > > Please not the first. Looks like a documentation bug to me. Phew! I was hoping for that response. > > Please feel free to submit a patch and ticket for this. Sure - thing - so now I will have to look at the how-tos for these . Ticket first, then patch, I assume. Regards, Andrew Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Software Foundations & Verification Research Group School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS big comment conventions
Hi Gedare, thanks for your analysis and comments! > On 22 Oct 2020, at 17:22, Gedare Bloom wrote: > > For standalone tools it is really your choice. We would prefer > adoption of an easily maintained style consistent with some kind of > sane default. Given that Promela is based on C with the same comment syntax, I am happy to adopt the RTEMS C/C++ comment standards for my files. Regards, Andrew Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Software Foundations & Verification Research Group School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fatal exceptions on context-switching for more than two isolated threads
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? > -- > 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
Re: Fatal exceptions on context-switching for more than two isolated threads
On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai wrote: > > > > On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber > 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. 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
Re: Fatal exceptions on context-switching for more than two isolated threads
On Fri, Oct 23, 2020 at 9:57 PM Gedare Bloom wrote: > On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai > 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
