Re: [glob2-devel] new crash: “Segmentation Fault (SDL Parachute Deployed)” (no core dump file!)

[Joe Wells]

"Bradley Arsenault" <address@hidden> writes:

> Gdb will work properly, it has worked properly
> because I have done it, even with SDL parachutes. Let me tell you why: The
> program doesn't even recieve the signall. SDL can't intercept if it doesn't
> recieve a signall in the first place. This is because gdb intercepts the 
> signal
> before it reaches the program. Simple?

Thanks for pointing this out.  I had forgotten that gdb was configured
by default to stop the program on certain signals.

> Secondly, yes, for every combination of options I've used on my own programs
> during compiling, they have never given me a dump of anything for any signall
> that has been provided to them. They all exit without any result. I don't
> expect a result, I've never seen it, i've never heard anyone mention it when I
> first learned how to debug.

If you are using a Unix-based operating system and a Bourne-shell
derived shell like bash, run the “ulimit -c” command and see whether
an ancestor process (or maybe your own shell configuration files) has
set a size limit for core dump files.  If the size limit is 0, then
core dump files are not created at all.  If core dump files have been
limited, you will need to remove the limit on core dump size with
“ulimit -S -c unlimited”.  This might not work if some ancestor
process has set a “hard” limit.  If so, you need to find out which
ancestor process is setting the hard limit and stop it from doing so.
(By the way, the “ulimit” command is for Bourne shell derivatives; for
csh derivatives use the “limit” and “unlimit” commands.)

On Linux, it is also possible that core dump files have been disabled
system wide or put in a strange directory by modifying the contents of
/proc/sys/kernel/core_pattern.  Make sure the contents of this file is
just “core” and then you will get core dump files in the current
directory (if the current directory is writable).

> My personal preference is for gdb in any case, a
> backtrace from gdb usually gets the problem solved within minutes, so it does
> work in practice. I've never used a core dump, it would only complicate things
> for me.

You can get a backtrace from a core dump file using gdb.  You just
start gdb with the command “gdb PROGRAM-FILE CORE-DUMP-FILE”.  (You
can also load a core dump file from within gdb if you've already
started gdb.)  The backtrace you can get from a core dump file is the
exact same thing.

The main important thing is that a core dump file is vital if you
weren't already running gdb and can't reproduce the crash.

-- 
Joe