[PLUG] Cscope, SIGSEGV, do_coredump, GNU libc info

[Karl M. Hegbloom]

On Sun, 2002-12-08 at 13:21, Mark Martin wrote:
> Okay, I'll at least give you some information related to your original 
> question.  What I have to say pertains to C/C++ and I can't vouch for how 
> much will apply to other languages.

Well, for other languages that compile to real CPU assembler object
code, the similar is certainly possible -- that is, the program could
attempt to access RAM that is outside of the area allocated to itself,
and then the operating system would trap that attempt and ... Hmmm.  The
question we must answer is whether the program gets sent a SIGSEGV if it
has not registered a handler for it.  I do know for sure that the core
file is produced by kernel code, and not the C library.  Without
resorting to a manual...

Alright, I've got my XEmacs visiting the kernel-source-2.4.18, it's
loaded with "cscope" support, and I've got cscope indexes built. 
(apt-get bought me all of that, and it Just Works) I use the Cscope menu
to select "find symbol", and type "segv".  I find a bunch of references
to a "segv:" label in "signal.c", but none of them are for i386, so I
try again.  Let's try "sys_segv" once. Nothing.  Hmmm...  Next I try
"find egrep pattern", for "segv".  It's grinding away...

Ok, I find "goto give_sigsegv;" in "arch/i386/kernel/signal.c", and hit
enter on the top one to go take a look.  Here's what I find lower down:

give_sigsegv:
	if (sig == SIGSEGV)
		ka->sa.sa_handler = SIG_DFL;
	force_sig(SIGSEGV, current);

So now I put my cursor on "force_sig", and use the "find symbol" again
to track it down.  There's a bunch of hits... let's try again with "find
global definition".  Ok, this time only one hit, in "kernel/signal.c" on
line 693...  I track on into "force_sig_info", same file.  The comment
here says:

/*
 * Force a signal that the process can't ignore: if necessary
 * we unblock the signal and change any SIG_IGN to SIG_DFL.
 */

Now on into "send_sig_info", we find... our way on, through several
functions... and I've lost the trail.  I must find out where the process
actually becomes active, and where it checks for pending signals then
actually calls the handler or does the core dump.  Let's try another
tactic.  "find egrep pattern" for "core"... and scan by eyeball... Ah,
here.  "arch/i386/kernel/signal.c", line 683:

  if (do_coredump(signr, regs))

Alright, and there's a switch checking for signal names!  Let's "find
global definition" for "do_coredump" now.  Ah, and here's the kernel
actually creating a core file!  You'll notice that it's checking
"current->rlim[RLIMIT_CORE].rlim_cur" to see if you're "rlimit" for core
files is set high enough to make a core the size this one will be.

> The behavior of a program when there's a 
> segfault depends on the signal handler assigned to the SIGSEGV signal.  If 
> the program doesn't define a handler for the signal, then the default handler 
> is used.  The default signal handlers are "implementation-dependent", 
> according to the references I consulted, and I believe that they are part of 
> the C library.

A signal handler is generally code you write yourself.  It's sort of
rude for a library to take over a signal on you, unless that's well
documented.  (libgpm had issues wrt this, IIRC)

http://www.pdxlinux.org/cgi-bin/info2www?file=dir&query=%28libc%29Signal+Handling

> If you absolutely want a core dump on SIGSEGV, it sounds like you'll have to 
> implement a handler that exhibits this behavior.

There are some interesting SEGV handlers in some of the GNU software. 
The emacsen trap it and save your buffers before they crash, for
instance.  That's a lifesaver when you're using a development version to
develop a development version. :-)  The "Bug Buddy" dialog in Gnome is
done with a SEGV handler also.  I believe (IIRC) that KDE also has a
similar common widget.

> In case you're interested, the sources I looked at were
> 
> "A Book on C" by Kelly and Pohl
> "C A Reference Manual" by Harbison and Steele
> "Beginning Linux Programming" by Mathew and Stones
> 
> The man pages related to signals might also help you.

8-)

I highly recommend the GNU Lib C manual!

The book I learned C from was called "Workout C".  It was a very good
textbook.  It came with a C compiler for DOS.