Stack full or something else?

João Rasta freakforever at gmail.com
Fri Nov 12 13:05:41 CST 2010


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

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>wrote:

>
> On Fri, Nov 12, 2010 at 11:50 AM, João Rasta <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
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rtems.org/pipermail/rtems-users/attachments/20101112/8109ce4e/attachment.html>


More information about the rtems-users mailing list