Re: [ECOS] using threads causes exceptions

[Gary Thomas <gary at mlbassoc dot com>]

On Wed, 2005-08-03 at 18:27 +0200, Stefan Sommerfeld wrote:
> Hi,
> >> >> >>
> >> >> >> I'm using eCos on an XScale PXA270 and i have a problem using
> >> >> >> threads.
> >> >> >> My
> >> >> >> program does only start a thread from main() and after this 
> >> >> >> function
> >> >> >> calls
> >> >> >> from thread causes ABORT DATA exceptions (MMU info: Imprecise
> >> >> >> External
> >> >> >> Data
> >> >> >> Abort). Even a printf causes this exception. The strange thing is,
> >> >> >> the
> >> >> >> eCos
> >> >> >> thread tests are working, even the stress test. Do i have to do 
> >> >> >> some
> >> >> >> initialisation? Should i better use cyg_start() instead of main()?
> >> >> >
> >> >> > Using main() is just fine.  Most likely, you've not created the
> >> >> > stack for the thread correctly.  Or perhaps it's something within
> >> >> > your thread itself.
> >> >> >
> >> >> > Have you tried running the program using GDB?  Then you can catch
> >> >> > the culprit and know where to start looking.
> >> >>
> >> >> So ... made it through gdb which gave me:
> >> >> [New Thread 2]
> >> >>
> >> >> Program received signal SIGTRAP, Trace/breakpoint trap.
> >> >> [Switching to Thread 2]
> >> >> 0xa008c72c in main_stack ()
> >> >>
> >> >> This version is a bit smaller and does give me no exceptions like 
> >> >> ABORT
> >> >> DMA, but only the gdb output. Any suggestions?
> >> >
> >> > It's pretty obvious that you've not set your thread up properly
> >> > since it's trying to execute from the stack!  Look carefully at
> >> > how you created the thread - compare it against the examples and
> >> > tests.
> >>
> >> >From gdb it looks like a corrupt stack, but i don't why.
> >>
> >> > If you still can't figure out what's wrong, you could send a
> >> > *fragment* of your code, showing how you are creating the thread,
> >> > etc.  Note: we don't want/need to see your whole program, just
> >> > this portion.
> >>
> >> #define STACK_SIZE (CYGNUM_HAL_STACK_SIZE_TYPICAL*2)
> >>
> >> static cyg_thread thread_data;
> >> static cyg_handle_t thread_handle;
> >>
> >> static void decoder_audio(cyg_addrword_t data)
> >> {
> >>  diag_printf("i'm here\n");
> >>  // more complex C++ stuff here
> >>  // and a endless loop calling some methods
> >> }
> >>
> >>
> >> int main(void)
> >> {
> >>  void *stack = malloc(STACK_SIZE);
> >>
> >>  cyg_thread_create(0,                // Priority - just a number
> >>   test_thread,          // entry
> >    ^^^^^^^^^^^
> >
> > What is this?  It should be the entry point to your thread - maybe
> > 'decoder_audio'?
> 
> Yes, of course. I changed it to test_thread for the source snipp, but 
> actual entry is decode_audio. I see the diag_printf from the thread.

So that means that your thread is running, so it's probably not a
problem of how you've created the thread (it looks OK modulo your
editing change).

Now, you'll need to do some debugging in the "more complex C++ stuff".
Have you tried stepping through that code with GDB?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss