This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RTEMS-3.6.0 & Linux Stray Signal 11




On Thu, 20 Mar 1997, Hans Zuidam wrote:

> > Anthony Enache Brown wrote:
> > [file], all of the log files contain nothing but a "Stray signall 11". 
> Set the environment variable RTEMS_DEBUG (see _CPU_Fatal_error)
> and look with a debugger where you get your SIGSEGV.  If it's from
> a different location each time, then you are plagued by the infamous
> sig11 bad memory bug.  If the SIGSEGV is on the same location each
> time, then I would look at the _CPU_Context_Initialize function to
> see if the jmp_buf is properly initialised for your Linux version.

This is a great description of how to track down a SEGV.  This
one is pretty simple though, an area of library memory is being
overwritten.

Actually RTEMS_DEBUG is not an environment variable, it is a conditional
compilation directive.  Other nice debugging aids are STACK_CHECKER_ON
and STACK_CHECKER_REPORT_USAGE which enables dynamic stack bounds 
checking and have a task stack usage report printed at program exit.
Also the routine "malloc_dump()" prints out a useful information
on the heap.


> > BTW, I cannot run the test files by themselves, attempting to do
> > so results in a seg fault.  
> Can you look with a debugger where this is happening?  If it's
> before main() is called then your startup code is wrong (probably
> linking the wrong libraries) else it could be what I've described
> above.

Getting an unexpected module from a system library is the exact  
problem in this case.  The linux version of the rtems unix port
was done on what is now a very old version of linux
(Yggdrasil Fall 1994).  Until I got it back up on Redhat 4.0, no
one had gone to the trouble of submitting patches.  In that
time, conflicts had developed between rtems C library support
routines and those in system libraries.  This resulted in
the malloc stats structure being grabbed from a system library
instead of from rtems.  The first time the rtems code updated
the stats, it gets a SEGV.

--joel sherrill
Joel Sherrill                    Sr. Computer Scientist
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985