<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">In the past I have run into this situation. The problem was that the arrays were local variables to my task and were thus allocated on the stack. (I was using another RTOS at the time that has its source code printed in a thick book) My stack for the process was 256 bytes, the array was a total of 800 bytes, the array was allocated on the stack, the array blew the stack in a different task since the stacks were allocated contiguously. Relocating a variable in task A fixed a crashing problem in task B.<div><br></div><div>To fix the problem I told the compiler that the array was a "static" and the array was allocated on the heap instead of the stack.</div><div><br></div><div>Andrei</div><div><br></div><div><br><div><div>On 2010-November-15, at 11:13 AM, Joćo Rasta wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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<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">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 class="im">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 class="im"><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 class="im"><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 class="im"><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 class="im"><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 class="h5"><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 class="im"><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>
<a href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> 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 class="h5">
<br>
<br>
-- <br>
Joel Sherrill, Ph.D. Director of Research& Development<br>
<a href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> 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>
_______________________________________________<br>rtems-users mailing list<br><a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>http://www.rtems.org/mailman/listinfo/rtems-users<br></blockquote></div><br>
<br></div></body></html>