[ECOS] Synthetic Linux Target App Startup Problem

Joel Hansen JHANSEN7@cfl.rr.com
Sat Dec 14 13:42:00 GMT 2002


Thanks for the information.  I'll make sure assertations are enabled and
take a look at the stack size.  From what you say, it seems that a stack
overflow is the most probable cause.  I'll also take a look at the
constructor priorities.

Thanks for the help
Joel Hansen

----- Original Message -----
From: "Bart Veer" <bartv@ecoscentric.com>
To: <JHANSEN7@cfl.rr.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Saturday, December 14, 2002 11:57 AM
Subject: Re: [ECOS] Synthetic Linux Target App Startup Problem

> >>>>> "Joel" == Joel Hansen <JHANSEN7@cfl.rr.com> writes:
>     Joel> I've run into a problem I'm not sure where to look to fix.
>     Joel> I'm porting a fairly complex program to eCos under the Linux
>     Joel> synthetic target. The program compiles fine however when I
>     Joel> start it under GDB it hangs. I know it's using malloc to
>     Joel> request some sizeable blocks of memory. Initially (under
>     Joel> doug lea's memory mgt ) it hangs at :
>     Joel> In CYG_HAL_NEWSELECT () at heaps.cxx:19 CYG_MEMPOOL_DAMALLOC
>     Joel> through the code it loops through
>     Joel> hal_idle_thread_action......
>     Joel> Thinking it might be a memory limitation under the standard
>     Joel> synthetic configuration, I increased RAM using prior posting
>     Joel> guidance modifying the mlt_synth_i386_rom.ldi and .h files.
>     Joel> I increased memory and received the same error until I hit a
>     Joel> limitation where synth_entry.c errored when calling
>     Joel> cyg_hal_sys_brk().
> To me this sounds like a memory corruption or stack overflow problem
> somewhere in the application code rather than anything wrong in eCos.
> That code in heaps.cxx only runs once, fairly early during system
> initialization. That INIT_PRI(CYG_INIT_MEMALLOC) indicates the
> priority of the C++ constructor, see <cyg/infra/cyg_type.h> for the
> various priorities that are available. Unless your application has its
> own C++ objects constructed with a higher priority, this system
> constructor will run before any application code. Also at this stage
> the scheduler is not yet running, so there is no way to end up in the
> idle thread and that CYG_HAL_NEWSELECT() call is unlikely to happen
> anywhere else.
> However, if there are memory corruption or stack overflow problems
> then all bets are off. Possibly gdb is getting confused about the
> current state of the system, and you have to be sceptical when
> interpreting its output. Or possibly the code really is managing to
> jump into that constructor again, effectively recreating all heaps
> from scratch - not a good idea once your application has started
> running.
> There are a couple of things worth trying. First, if you have not done
> so already then make sure you have built eCos with assertions enabled
> (the CYGPKG_INFRA_DEBUG option). That is often a good way of catching
> bugs in application code caused by misunderstandings of how eCos
> works. Second, try increasing all application thread stack sizes by a
> large amount - stack overflows can have very strange effects. Note
> that the synthetic target needs rather larger stacks than ordinary
> embedded targets because of the way it uses signal handling:
> Bart
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss

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

More information about the Ecos-discuss mailing list