Stack full or something else?
João Rasta
freakforever at gmail.com
Mon Nov 15 18:13:23 UTC 2010
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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20101115/e19455f6/attachment-0001.html>
More information about the users
mailing list