Fatal exceptions on context-switching for more than two isolated threads
Sebastian Huber
sebastian.huber at embedded-brains.de
Thu Nov 19 09:03:34 UTC 2020
On 18/11/2020 18:53, Utkarsh Rai wrote:
>
>
> On Wed, 18 Nov, 2020, 11:20 PM Gedare Bloom, <gedare at rtems.org
> <mailto:gedare at rtems.org>> wrote:
>
> Hi Utkarsh,
>
> I think I would like to see you try to unify the design so it works
> the same with or without stack protections. In other words, redesign
> these iterators to avoid inter-stack references between threads. Note
> also Sebastian's last comment about nested iteration. Depending on the
> design, to do this might require allocating space from the workspace
> instead, and therefore using the configuration to control the
> allocation limit. I can't be certain, but you might want to sketch out
> a design idea first for how to make the iterators independent of the
> thread stacks.
>
> Gedare
>
>
>
> Okay, I will look into this.
The support for nested iterations is necessary. I added an assert like this:
diff --git a/cpukit/score/src/userextiterate.c
b/cpukit/score/src/userextiterate.c
index 06665a2d7a..e3aaae452f 100644
--- a/cpukit/score/src/userextiterate.c
+++ b/cpukit/score/src/userextiterate.c
@@ -190,6 +190,7 @@ void _User_extensions_Iterate(
if ( executing != NULL ) {
iter.previous = executing->last_user_extensions_iterator;
+ _Assert( executing->last_user_extensions_iterator == NULL );
executing->last_user_extensions_iterator = &iter;
}
This assertion fails on a couple of tests, for example psxcleanup.exe:
Breakpoint 5, _Terminate (the_source=RTEMS_FATAL_SOURCE_ASSERT,
the_error=2136680) at ../../../cpukit/score/src/interr.c:36
36 _User_extensions_Fatal( the_source, the_error );
(gdb) bt
#0 _Terminate (the_source=RTEMS_FATAL_SOURCE_ASSERT, the_error=2136680)
at ../../../cpukit/score/src/interr.c:36
#1 0x00101186 in rtems_fatal (fatal_source=RTEMS_FATAL_SOURCE_ASSERT,
error_code=2136680) at ../../../cpukit/include/rtems/fatal.h:86
#2 0x001011f0 in __assert_func (file=0x12b6b4
"../../../cpukit/score/src/userextiterate.c", line=193, func=0x12b6e0
<__func__.3> "_User_extensions_Iterate", failedexpr=0x12b680
"executing->last_user_extensions_iterator == NULL") at
../../../cpukit/libcsupport/src/__assert.c:52
#3 0x00118b54 in _User_extensions_Iterate (arg=0x201f80
<_POSIX_Threads_Objects+1304>, visitor=0x118a61
<_User_extensions_Thread_terminate_visitor>,
direction=CHAIN_ITERATOR_BACKWARD) at
../../../cpukit/score/src/userextiterate.c:193
#4 0x00116256 in _User_extensions_Thread_terminate (executing=0x201f80
<_POSIX_Threads_Objects+1304>) at
../../../cpukit/include/rtems/score/userextimpl.h:461
#5 0x0011667c in _Thread_Life_action_handler (executing=0x201f80
<_POSIX_Threads_Objects+1304>, action=0x2021c4
<_POSIX_Threads_Objects+1884>, lock_context=0x209b0c) at
../../../cpukit/score/src/threadrestart.c:320
#6 0x00110a18 in _Thread_Run_post_switch_actions (executing=0x201f80
<_POSIX_Threads_Objects+1304>) at
../../../cpukit/score/src/threaddispatch.c:250
#7 0x00110b56 in _Thread_Do_dispatch (cpu_self=0x2005c0
<_Per_CPU_Information>, level=1611596115) at
../../../cpukit/score/src/threaddispatch.c:328
#8 0x00110b82 in _Thread_Dispatch_direct (cpu_self=0x2005c0
<_Per_CPU_Information>) at ../../../cpukit/score/src/threaddispatch.c:359
#9 0x0010943a in pthread_exit (value_ptr=0x0) at
../../../cpukit/posix/src/pthreadexit.c:38
#10 0x001092a6 in _POSIX_Threads_Exitted_extension (executing=0x201f80
<_POSIX_Threads_Objects+1304>) at
../../../cpukit/posix/src/pthreadcreate.c:470
#11 0x00118a26 in _User_extensions_Thread_exitted_visitor
(executing=0x201f80 <_POSIX_Threads_Objects+1304>, arg=0x201f80
<_POSIX_Threads_Objects+1304>, callouts=0x2001d0
<_POSIX_Threads_User_extensions+20>) at
../../../cpukit/score/src/userextiterate.c:116
#12 0x00118b88 in _User_extensions_Iterate (arg=0x201f80
<_POSIX_Threads_Objects+1304>, visitor=0x118a09
<_User_extensions_Thread_exitted_visitor>,
direction=CHAIN_ITERATOR_FORWARD) at
../../../cpukit/score/src/userextiterate.c:205
#13 0x0011101a in _User_extensions_Thread_exitted (executing=0x201f80
<_POSIX_Threads_Objects+1304>) at
../../../cpukit/include/rtems/score/userextimpl.h:425
#14 0x001110da in _Thread_Handler () at
../../../cpukit/score/src/threadhandler.c:152
You cannot use the workspace in this environment.
There are a couple of other areas in RTEMS in which the stack of another
thread may be accessed (events, message queues, signals). How did you
solve this?
One option is to temporarily disable the thread stack protection in
these areas. Something like:
state = disable_thread_stack_protection();
/* Access stack of another thread */
restore_thread_stack_protection(state);
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
More information about the devel
mailing list