Stack full or something else?
Andrei Chichak
groups at chichak.ca
Mon Nov 15 18:49:14 UTC 2010
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.
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.
Andrei
On 2010-November-15, at 11:13 AM, João Rasta wrote:
> Hi Joel,
>
> 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..
>
> 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?
>
>
> Best,
> JM
>
>
> On Mon, Nov 15, 2010 at 5:43 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
> On 11/15/2010 11:24 AM, João Rasta wrote:
> 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
>
> 0x40040d88 <rtems_semaphore_obtain+192>: ld [ %l3 ], %g1
> 0x40040d8c <rtems_semaphore_obtain+196>: call 0x400410c8 <_Semaphore_Translate_core_mutex_return_code>
> 0x40040d90 <rtems_semaphore_obtain+200>: ld [ %g1 + 0x34 ], %o0
> 0x40040e20 <rtems_semaphore_obtain+344>: b 0x40040d8c <rtems_semaphore_obtain+196>
> 0x40040e24 <rtems_semaphore_obtain+348>: ld [ %l3 ], %g1
> 0x40040ed8 <rtems_semaphore_obtain+528>: b 0x40040d8c <rtems_semaphore_obtain+196>
> 0x40040edc <rtems_semaphore_obtain+532>: ld [ %l3 ], %g1
>
> And Stack copy:
>
> Thread [3] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)
> 3 rtems_semaphore_obtain() c:\opt\rtems-4.10-mingw\src\rtems-4.10\cpukit\rtems\src\semobtain.c:90 0x40040edc
> 2 <symbol is not available> 0x00000008
> 1 <symbol is not available> 0x0000000c
>
> If this is the backtrace, somehow the stack pointer has gotten
> corrupted.
>
> The last value i could get from %g1 is 0.
> If this task is not blowing its stack, then we are left with a couple
> of guesses:
>
> + another task is blowing its stack and corrupting memory
> that impacts this task.
> + stray write is corrupting something.
>
> When did you see the %g1 have 0? What was the last instruction?
> Where was it loading from?
>
> Here's how i'm configuring semaphores:
>
> #define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES 15
>
> This only affects POSIX semaphores sem_XXX.
>
>
> Any hints on what it can be failing? Should i set CONFIGURE_MAXIMUM_SEMAPHORES as well?
>
> I doubt it since you appear to be completing a semaphore_obtain.
> That means (probably) that a semaphore_create worked.
>
> Do a backtrace in gdb. I suspect you will find you are coming from a subsystem
> like termios.
>
> -joel
>
> Best,
> JM
>
>
>
>
>
> On Fri, Nov 12, 2010 at 7:34 PM, Joel Sherrill <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>> wrote:
>
> On 11/12/2010 01:05 PM, João Rasta wrote:
>
> Hi Daron,
>
> It is running on a LEON-3. The application exits raising the
> following exception:
>
> IU in error mode (tt = 0x07)
>
> which is a memory access to an unaligned address. The last
> instruction is this:
>
> 4003bd74 d0006034 ld [%g1 + 0x34], %o0
>
> What is the value of g1? Is it unaligned?
>
> I don't understand why i have this error. The code where this
> error is being reported is compiled independently and then put
> in a library, but it uses the same cross-compiler as the main
> source code. I don't think i'm doing something wrong while
> compiling the library files, i use the same compilation flags..
>
> What can i be missing to have unaligned memory accesses?
>
>
> Best,
> JM
>
>
>
> On Fri, Nov 12, 2010 at 6:43 PM, Daron Chabot
> <daron.chabot at gmail.com <mailto:daron.chabot at gmail.com>
> <mailto:daron.chabot at gmail.com
> <mailto:daron.chabot at gmail.com>>> wrote:
>
>
> On Fri, Nov 12, 2010 at 11:50 AM, João Rasta
> <freakforever at gmail.com <mailto:freakforever at gmail.com>
> <mailto:freakforever at gmail.com
>
> <mailto:freakforever at gmail.com>>> wrote:
>
> Hi,
>
> I have an RTEMS POSIX API application which comes to a
> point
> that if a small function (with some doubles passed as
> arguments) is called, the application exits with an
> error. At
> first i thought of increasing the stack space. I did
> this with
> CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE but the problem
> remains
> even if i remove all the contents of the function.
>
> 1) Am i setting up the stack size correctly? I think i
> am, but
> i ask just in case..
>
> 2) Is there any other explanation to why a function call
> crashes the application besides having a full stack?
> Again, i
> erased the function contents..
>
>
> What architecture is this running on ?
>
> What is the application exit error (message and/or return
> code)?
>
> It looks like all POSIX threads are created as floating-point
> tasks (FP state saved across context switches), so there
> "shouldn't" be a problem on that aspect...
>
>
>
> Best,
> JM
>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org <mailto:rtems-users at rtems.org>
> <mailto:rtems-users at rtems.org <mailto:rtems-users at rtems.org>>
>
>
> http://www.rtems.org/mailman/listinfo/rtems-users
>
>
>
>
>
> -- Joel Sherrill, Ph.D. Director of Research& Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>
>
>
>
>
> --
> Joel Sherrill, Ph.D. Director of Research& Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20101115/709d6136/attachment-0001.html>
More information about the users
mailing list