Stack full or something else?

João Rasta freakforever at gmail.com
Mon Nov 15 17:24:19 UTC 2010


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

The last value i could get from %g1 is 0. Here's how i'm configuring
semaphores:

#define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES            15


Any hints on what it can be failing? Should i set
CONFIGURE_MAXIMUM_SEMAPHORES as well?


Best,
JM




On Fri, Nov 12, 2010 at 7:34 PM, Joel Sherrill <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>> wrote:
>>
>>
>>    On Fri, Nov 12, 2010 at 11:50 AM, João Rasta
>>    <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>
>>
>>        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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20101115/5a8064d5/attachment-0001.html>


More information about the users mailing list