Re: Tracking down a SEGFAULT

For tracking down segmentation faults we use the remote debugging with gdb.
We just run the application on the target with the debugger running on 
the host. When the segmentation occurs, the gdb shows the exact line 
causing the problem.


Shane Volpe wrote:
> I have been tracking down a SEGFAULT on my ARM system for the last
> several days and have made very little progress.  I'm posting to this
> list to get feedback on good methods for tracking down a SEGFAULT,
> here is what I have done to date:
> 1.) Reviewed all code in question with no luck.
> 2.) Enabled kernel user_debug, this helped a little but did not give
> any real insight.
> 3.) Loaded the coredump into gdb, this did not provide anything useful
> as it seems to be a broken method do to the following issue:
> http://gcc.gnu.org/ml/gcc/2008-11/msg00314.html
>
> The above link explains that coredumps are useless on the ARM due to
> how gcc optimizes non-returning functions.  I do not fully understand
> this issue and would like feedback on if there is some way I can fix
> it in my build?  Can I just recompile my application with -O0 option
> or would I also need to recompile glibc with that option as well.
>
> Is there a better method for tracking down SEGFAULTs that I have missed?
>
> Regards,
> Shane
>
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
> FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
>
>   


-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php