This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Synthetic Linux Target App Startup Problem
Bart
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> CYGMEM_POOL_HEAP1 ((CYG_UNIT8 *) CYGMEM_SECTION_HEAP1,
> Joel> CYGMEM_SECTION_HEAP!_SIZE)
> Joel> CYGBID_ATTRIB_INIT_PRI(CYG_INIT_MEMALLOC) then stepping
> 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:
> CYGNUM_HAL_STACK_SIZE_TYPICAL is set to 32K.
>
> 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