Re: [ECOS] idle thread stack full?

["Michele Paselli" <triguelon at gmail dot com>]

I tried to fix the problem but now this is what I get.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0006d9c0 in cyg_libc_main_stack ()

This time I tried to backtrace with gdb and this is what I get:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0006d9c0 in cyg_libc_main_stack ()
(gdb) info threads
  6 thread 6 ( Name: Ethernet2Radio Thread, State: sleeping, Priority:
4 )  0x0006a2ec in eth2radio_thread_obj ()
  5 thread 5 ( Name: Radio2Ethernet Thread, State: sleeping, Priority:
2 )  0x0006a24c in radio2eth_thread_obj ()
  4 thread 4 ( Name: main, State: exited, Priority: 10 )  0x0006bca0
in cyg_libc_main_thread ()
  3 thread 3 ( Name: Raw Ethernet TX Thread, State: sleeping,
Priority: 3 )  0x00078474 in raweth_tx_thread_obj ()
  2 thread 2 ( Name: Raw Ethernet RX Thread, State: sleeping,
Priority: 3 )  0x000783d4 in raweth_rx_thread_obj ()
* 1 thread 1 ( Name: Idle Thread, State: running, Priority: 31 )
0x0006d9c0 in cyg_libc_main_stack ()
(gdb) thread 1
[Switching to thread 1 (thread 1)]#0  0x0006d9c0 in cyg_libc_main_stack ()
(gdb) bt
#0  0x0006d9c0 in cyg_libc_main_stack ()
#1  0x0006d9c4 in cyg_libc_main_stack ()
Previous frame identical to this frame (corrupt stack?)
(gdb)

I had monitored all the threads that I create and none of them is
running out of stack, in any case they're all sleeping when I get the
SIGTRAP, so how can they corrupt some stacks? I backtraced all the
threads (I don't put here the results but I have them in case of need)
and they're all waiting for some condition variable or semaphore (or
at least it seems to me) and they end up in they respective objects
after an unlock_inner(). The only one behaving differently is the main
thread:

(gdb) thread 4
[Switching to thread 4 (thread 4)]#0  0x0006bca0 in cyg_libc_main_thread ()
(gdb) bt
#0  0x0006bca0 in cyg_libc_main_thread ()
#1  0x00048a98 in Cyg_Scheduler::unlock_inner (new_lock=1)
    at /imecnl/software/common/ecos/opt/ecos/ecos-2.0.43/packages/kernel/v2_0_43/src/sched/sched.cxx:207
#2  0x00051564 in _exit (status=435980)
    at /imecnl/software/common/ecos/opt/ecos/ecos-2.0.43/packages/language/c/libc/startup/v2_0_43/src/_exit.cxx:96
#3  0x0005130c in exit (status=0)
    at /imecnl/software/common/ecos/opt/ecos/ecos-2.0.43/packages/language/c/libc/startup/v2_0_43/src/exit.cxx:100
#4  0x000504bc in cyg_libc_invoke_main ()
    at /imecnl/software/common/ecos/opt/ecos/ecos-
2.0.43/packages/language/c/libc/startup/v2_0_43/src/invokemain.cxx:123
#5  0x00047248 in Cyg_HardwareThread::thread_entry (thread=0x6bca0)
    at /imecnl/software/common/ecos/opt/ecos/ecos-2.0.43/packages/kernel/v2_0_43/src/common/thread.cxx:110
#6  0x00047204 in Cyg_Thread::exit ()
    at /imecnl/users/paselli/industrial-MSN/raw_eth_optim/master/fmtc_install/include/cyg/kernel/sched.hxx:394
Cannot access memory at address 0xdeadbeeb
(gdb)

which is also labeled as "exited". What does it means? Is anything
else that I can check? Thanks.

Michele


On 10/23/07, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Oct 23, 2007 at 06:56:04PM +0200, Michele Paselli wrote:
> > Hi,
> >
> > I have an application with 6 threads running and after a while gdb
> > stops and I get this message.
> >
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > 0x0006c7dc in idle_thread_stack ()
> >
> > The address is in RAM and it belongs to the idle thread, is it
> > possible that I'm filling completely the idle thread stack? When I
> > increase the stack size the application run without errors for more
> > time but since I set the option to have a separate stack for
> > interrupts I don't understand who's filling the idle thread stack, am
> > I missing something?
>
> It probably is not the idle thread which is causing the problem. Any
> stack which is corrupted or overflowed could cause a jump which lands
> in the idle stack. Can you get a backtrace from gdb? That might give
> you a clue.
>
>     Andrew
>

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