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