From: Gennady Bystritsky <gfb@...>
Date: 2005-07-04T01:02:56+09:00
Subject: Re: Ruby/Gosu


On Jul 3, 2005, at 6:10, Kevin Pratt wrote:

...
> On to the question.....
>
> What would be the best way to debug this problem?  I need to find out
> where the segfault is happening.  In ruby because of the SO, in the
> Gosu SO because of invalid memory access etc.
>
> Any thoughts would be appreciated.
>
> Kevin Pratt
>
>

Ruby handles all signals by itself. It is great most of the time  
except when a segfault occurs and you need to figure out where. For  
such cases I usually end up resetting a signal handling to the  
default either by compiling a custom ruby or from a C extension that  
I load first. For segmentation fault it would be:

#include <signal.h>
...
signal(SIGSEGV, SIG_DFL);

When a problem occurs, you will have a core dump, which may help you  
in figuring out where it happened (providing the stack is not  
corrupted beyond recognition, gdb's command "bt" shows you the stack  
trace). Make sure core dumps are allowed on you system. "ulimit -c"  
shows you the limit for core file size. It is 0 (cores disabled) by  
default on some systems. Use "ulimit -c unlimited" to to remove the  
limitation for the current session.

Hope it helps,
Gennady.