I increased the stack sizes, but now i seem to be having trouble with the register windows. Now gdb complaints when performing a "ret" after getting out of a function:<br><br>0x4000a534 <mdlOutputs+328>: std %f8, [ %l5 + 8 ]<br>
}<br>0x4000a53c <mdlOutputs+336>: ret <<<<---- SEG FAULT<br>0x4000a540 <mdlOutputs+340>: restore <br><br>Here's the Stack copy:<br><br>Thread [3] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) <br>
6 mdlOutputs() C:\opt\build\Real_GNC\code\GNC\source\guidance_s.c:373 0x4000a53c <br> 5 gnc_output() C:\opt\build\Real_GNC\model\backups\gnc_linux\gnc.c:307 0x40008d80 <br> 4 Execute_gnc() C:\opt\build\Real_GNC\model\backups\gnc_linux\gnc_wrapper.c:116 0x4000a180 <br>
3 task_main() C:\opt\build\Real_GNC\src\shell\gnc_scheduler_task.c:125 0x40006144 <br> 2 _Thread_Handler() c:\opt\rtems-4.10-mingw\src\rtems-4.10\cpukit\score\src\threadhandler.c:156 0x4003bdb0 <br> 1 _Thread_Handler() c:\opt\rtems-4.10-mingw\src\rtems-4.10\cpukit\score\src\threadhandler.c:87 0x4003bc88 <br>
<br>What could be generating such a problem? Do i need to change any RTEMS configuration related to the register windows?<br><br><br>Best,<br>JM<br><br><br><br><br><div class="gmail_quote">On Mon, Nov 15, 2010 at 9:18 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@gwmail.gwu.edu">gedare@gwmail.gwu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">That should work with posix, at least to increase the amount of space pre-allocated for task stacks. You will also need to ensure that you use a large enough value of pthread_attr_t->stacksize when you call pthread_create().<br>
<br>The suggestion to declare your large arrays as static can work in case your function is non-reentrant, otherwise you have to worry about sharing.<br><font color="#888888"><br>-G</font><div><div></div><div class="h5">
<br><br><div class="gmail_quote">On Mon, Nov 15, 2010 at 3:15 PM, Joćo Rasta <span dir="ltr"><<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Gedare,<br><br>Will CONFIGURE_EXTRA_TASK_STACKS also work with the POSIX API?<br><br><br>
Best,<br>JM<div><div></div><div><br><br><div class="gmail_quote">On Mon, Nov 15, 2010 at 6:34 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@gwmail.gwu.edu" target="_blank">gedare@gwmail.gwu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Joćo,<br><br>You can configure extra space for all of your tasks like this:<br> #define CONFIGURE_EXTRA_TASK_STACKS (RTEMS_MINIMUM_STACK_SIZE * ??)<br>
Where you put ?? to make it a multiple of min stack size, or you can just put an arbitrary number of bytes.<br>
<br>Otherwise you can increase the stack_size argument to rtems_task_create for a particular task.<br><br>You might also try configuring with CONFIGURE_STACK_CHECKER_ENABLED defined. It does some extra checks for stack bounds and might give you a tighter window for debugging where the problem is occurring.<br>
<font color="#888888">
<br>-Gedare</font><div><div></div><div><br><br><br><div class="gmail_quote">On Mon, Nov 15, 2010 at 1:13 PM, Joćo Rasta <span dir="ltr"><<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Joel,<br><br>Good point. I have a task that is heavy on memory operations (multi-size array operations and so on). It also has a lot of doubles so it can also be corrupting its stack. Too bad it is 'silent' when corrupting the memory one way or another.. <br>
<br>To eliminate the stack overflow issue, i guess it is not enough to increase the initial task stack size. Is there a way to control the subsequent called task stack sizes?<br><br><br>Best,<br>JM<div><div></div><div>
<br><br><br><div class="gmail_quote">
On Mon, Nov 15, 2010 at 5:43 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On 11/15/2010 11:24 AM, Joćo Rasta wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
After some hard debuggin' with gdb i found out that this error is occurring at _Semaphore_Translate_core_mutex_return_code() but i still don't know why it happens. Here's the disassembly of the code where the error is generated<br>
<br>
0x40040d88 <rtems_semaphore_obtain+192>: ld [ %l3 ], %g1<br>
0x40040d8c <rtems_semaphore_obtain+196>: call 0x400410c8 <_Semaphore_Translate_core_mutex_return_code><br>
0x40040d90 <rtems_semaphore_obtain+200>: ld [ %g1 + 0x34 ], %o0<br>
0x40040e20 <rtems_semaphore_obtain+344>: b 0x40040d8c <rtems_semaphore_obtain+196><br>
0x40040e24 <rtems_semaphore_obtain+348>: ld [ %l3 ], %g1<br>
0x40040ed8 <rtems_semaphore_obtain+528>: b 0x40040d8c <rtems_semaphore_obtain+196><br>
0x40040edc <rtems_semaphore_obtain+532>: ld [ %l3 ], %g1<br>
<br>
And Stack copy:<br>
<br>
Thread [3] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)<br>
3 rtems_semaphore_obtain() c:\opt\rtems-4.10-mingw\src\rtems-4.10\cpukit\rtems\src\semobtain.c:90 0x40040edc<br>
2 <symbol is not available> 0x00000008<br>
1 <symbol is not available> 0x0000000c<br>
<br>
</blockquote></div>
If this is the backtrace, somehow the stack pointer has gotten<br>
corrupted.<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The last value i could get from %g1 is 0. <br>
</blockquote></div>
If this task is not blowing its stack, then we are left with a couple<br>
of guesses:<br>
<br>
+ another task is blowing its stack and corrupting memory<br>
that impacts this task.<br>
+ stray write is corrupting something.<br>
<br>
When did you see the %g1 have 0? What was the last instruction?<br>
Where was it loading from?<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Here's how i'm configuring semaphores:<br>
<br>
#define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES 15<br>
<br>
</blockquote></div>
This only affects POSIX semaphores sem_XXX.<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Any hints on what it can be failing? Should i set CONFIGURE_MAXIMUM_SEMAPHORES as well?<br>
<br>
</blockquote></div>
I doubt it since you appear to be completing a semaphore_obtain.<br>
That means (probably) that a semaphore_create worked.<br>
<br>
Do a backtrace in gdb. I suspect you will find you are coming from a subsystem<br>
like termios.<br>
<br>
-joel<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Best,<br>
JM<div><br>
<br>
<br>
<br>
<br>
On Fri, Nov 12, 2010 at 7:34 PM, Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a> <mailto:<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>>> wrote:<br>
<br>
On 11/12/2010 01:05 PM, Joćo Rasta wrote:<br>
<br>
Hi Daron,<br>
<br>
It is running on a LEON-3. The application exits raising the<br>
following exception:<br>
<br>
IU in error mode (tt = 0x07)<br>
<br>
which is a memory access to an unaligned address. The last<br>
instruction is this:<br>
<br>
4003bd74 d0006034 ld [%g1 + 0x34], %o0<br>
<br>
What is the value of g1? Is it unaligned?<br>
<br>
I don't understand why i have this error. The code where this<br>
error is being reported is compiled independently and then put<br>
in a library, but it uses the same cross-compiler as the main<br>
source code. I don't think i'm doing something wrong while<br>
compiling the library files, i use the same compilation flags..<br>
<br>
What can i be missing to have unaligned memory accesses?<br>
<br>
<br>
Best,<br>
JM<br>
<br>
<br>
<br>
On Fri, Nov 12, 2010 at 6:43 PM, Daron Chabot<br>
<<a href="mailto:daron.chabot@gmail.com" target="_blank">daron.chabot@gmail.com</a> <mailto:<a href="mailto:daron.chabot@gmail.com" target="_blank">daron.chabot@gmail.com</a>><br>
<mailto:<a href="mailto:daron.chabot@gmail.com" target="_blank">daron.chabot@gmail.com</a><br>
<mailto:<a href="mailto:daron.chabot@gmail.com" target="_blank">daron.chabot@gmail.com</a>>>> wrote:<br>
<br>
<br>
On Fri, Nov 12, 2010 at 11:50 AM, Joćo Rasta<br>
<<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a> <mailto:<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a>><br></div>
<mailto:<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a><div><div></div><div><br>
<mailto:<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a>>>> wrote:<br>
<br>
Hi,<br>
<br>
I have an RTEMS POSIX API application which comes to a<br>
point<br>
that if a small function (with some doubles passed as<br>
arguments) is called, the application exits with an<br>
error. At<br>
first i thought of increasing the stack space. I did<br>
this with<br>
CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE but the problem<br>
remains<br>
even if i remove all the contents of the function.<br>
<br>
1) Am i setting up the stack size correctly? I think i<br>
am, but<br>
i ask just in case..<br>
<br>
2) Is there any other explanation to why a function call<br>
crashes the application besides having a full stack?<br>
Again, i<br>
erased the function contents..<br>
<br>
<br>
What architecture is this running on ?<br>
<br>
What is the application exit error (message and/or return<br>
code)?<br>
<br>
It looks like all POSIX threads are created as floating-point<br>
tasks (FP state saved across context switches), so there<br>
"shouldn't" be a problem on that aspect...<br>
<br>
<br>
<br>
Best,<br>
JM<br>
<br>
<br>
<br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a> <mailto:<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a>><br></div></div>
<mailto:<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a> <mailto:<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a>>><div><br>
<br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
<br>
<br>
<br>
<br>
<br>
-- Joel Sherrill, Ph.D. Director of Research& Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
<br>
<br>
<br>
</div></blockquote><div><div></div><div>
<br>
<br>
-- <br>
Joel Sherrill, Ph.D. Director of Research& Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
<br>
<br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
<br></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>