[ECOS] Synthetic Linux Target App Startup Problem

Bart Veer bartv@ecoscentric.com
Sat Dec 14 09:02:00 GMT 2002


>>>>> "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



More information about the Ecos-discuss mailing list