Stack full or something else?
Joel Sherrill
joel.sherrill at OARcorp.com
Tue Nov 16 14:36:52 UTC 2010
On 11/16/2010 06:37 AM, João Rasta wrote:
> Eheh i done it :) . The problems were in code generated from the
> matlab real-time workshop from a simulation i have with blocks working
> at different rates. So now i tried to run the model advisor tool and
> fixed some code generation process options that were wrong. For
> instance, it was generating code for emulation, which was not needed
> in the final implementation. And it was set for single-tasking instead
> of multitasking. I then attached this OK generated code to my
> communications layer, all under RTEMS as i was doing before but with
> the bad generated code, and now it works perfectly.
>
> Basically it was a RTW code generation problem.
>
Can you please add a page to the Wiki on MatLab? I jhave added a
link to the new page so all you have to do is fill in some details.
http://wiki.rtems.org/wiki/index.php?title=MATLABCodeGeneration&action=edit&redlink=1
Is RTEMS support included with MATLAB? Special options,
any portability or target architecture issues, etc.
Any information on what is required to do this is useful. I know
people use MATLAB generated code with RTEMS but that is the
extent of my knowledge and what is in the Wiki right now.
Thanks.
>
> Sincerely, thank you all.
>
> Best,
> JM
>
> On Tue, Nov 16, 2010 at 12:09 PM, João Rasta <freakforever at gmail.com
> <mailto:freakforever at gmail.com>> wrote:
>
> I increased the stack sizes, but now i seem to be having trouble
> with the register windows. Now gdb complaints when performing a
> "ret" after getting out of a function:
>
> 0x4000a534 <mdlOutputs+328>: std %f8, [ %l5 + 8 ]
> }
> 0x4000a53c <mdlOutputs+336>: ret <<<<---- SEG FAULT
> 0x4000a540 <mdlOutputs+340>: restore
>
> Here's the Stack copy:
>
>
> Thread [3] (Suspended: Signal 'SIGSEGV' received. Description:
> Segmentation fault.)
> 6 mdlOutputs()
> C:\opt\build\Real_GNC\code\GNC\source\guidance_s.c:373 0x4000a53c
> 5 gnc_output()
> C:\opt\build\Real_GNC\model\backups\gnc_linux\gnc.c:307 0x40008d80
> 4 Execute_gnc()
> C:\opt\build\Real_GNC\model\backups\gnc_linux\gnc_wrapper.c:116
> 0x4000a180
> 3 task_main()
> C:\opt\build\Real_GNC\src\shell\gnc_scheduler_task.c:125 0x40006144
> 2 _Thread_Handler()
> c:\opt\rtems-4.10-mingw\src\rtems-4.10\cpukit\score\src\threadhandler.c:156
> 0x4003bdb0
> 1 _Thread_Handler()
> c:\opt\rtems-4.10-mingw\src\rtems-4.10\cpukit\score\src\threadhandler.c:87
> 0x4003bc88
>
> What could be generating such a problem? Do i need to change any
> RTEMS configuration related to the register windows?
>
>
> Best,
> JM
>
>
>
>
>
> On Mon, Nov 15, 2010 at 9:18 PM, Gedare Bloom
> <gedare at gwmail.gwu.edu <mailto:gedare at gwmail.gwu.edu>> wrote:
>
> That should work with posix, at least to increase the amount
> of space pre-allocated for task stacks. You will also need to
> ensure that you use a large enough value of
> pthread_attr_t->stacksize when you call pthread_create().
>
> The suggestion to declare your large arrays as static can work
> in case your function is non-reentrant, otherwise you have to
> worry about sharing.
>
> -G
>
>
> On Mon, Nov 15, 2010 at 3:15 PM, João Rasta
> <freakforever at gmail.com <mailto:freakforever at gmail.com>> wrote:
>
> Hi Gedare,
>
> Will CONFIGURE_EXTRA_TASK_STACKS also work with the POSIX API?
>
>
> Best,
> JM
>
>
> On Mon, Nov 15, 2010 at 6:34 PM, Gedare Bloom
> <gedare at gwmail.gwu.edu <mailto:gedare at gwmail.gwu.edu>> wrote:
>
> João,
>
> You can configure extra space for all of your tasks
> like this:
> #define CONFIGURE_EXTRA_TASK_STACKS
> (RTEMS_MINIMUM_STACK_SIZE * ??)
> Where you put ?? to make it a multiple of min stack
> size, or you can just put an arbitrary number of bytes.
>
> Otherwise you can increase the stack_size argument to
> rtems_task_create for a particular task.
>
> You might also try configuring with
> CONFIGURE_STACK_CHECKER_ENABLED defined. It does some
> extra checks for stack bounds and might give you a
> tighter window for debugging where the problem is
> occurring.
>
> -Gedare
>
>
>
> On Mon, Nov 15, 2010 at 1:13 PM, João Rasta
> <freakforever at gmail.com
> <mailto:freakforever at gmail.com>> 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
> <mailto: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>
> <mailto: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>>
> <mailto: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>>
> <mailto: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>>
> <mailto: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 <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
More information about the users
mailing list