Segmentation fault

[Mark Donnelly]

On Sun, 6 Feb 2000, Brad Noyes wrote:

> I'm writing a c++ program that before i changed distributions from RH6.0, to
> Mandrake worked. But now i try to run it i get a Segmentation fault when i
> execute it with no core dump.

Seg faults: the wonderful, wonderful sign of memory leaks.  aaahhhh..

You're probably doing one of two things: first, you might be allocating
memory and forgetting to free it again when you are finished (less
likely), or using some bit of memory before you allocate it (more likely).

For an example of the latter, here's some C code:

int main()
{
	int *ret_param;
	
	some_function_call(1, 13, ret_param);
	
	exit;
}

The problem here is that you don't really know what ret_param really is
until you do a malloc (or a new).  It's the right type, but you could be
pointing anywhere.

What changes from RH6.0 to Mandrake?  As someone else pointed out,
libraries.  Your libraries now occupy different spaces in logical memory
(how the app sees memory space).  This happens because the libraries are
just different; even with the same source, Mandrake compiles with pentium
optimizations.  Thus, a pointer reference that worked before - because it
pointed to nowhere - might now no longer work because it points to a
library.

> Is there anyway that i can figure out why it is
> seg faulting with gdb, or something? 

gdb might help with a core dump; more on that in a moment.  Just running
it under gdb probably won't help you much; in my experience gdb tends to
alter the memory map enough for freaky memory problems to suddenly not be
problems anymore.

What to do then?  First, listen for warnings!  The compiler really means
those warnings (even if the Apple compiler has fun messages like 'Found /*
within a comment, this worries me...').  Compile the program with a -Wall
(all warnings).  This will give you a lot, but it tends to make your
program work better.

What else?  I can't remember the name, but there is a library that you can
link against that provides a malloc/free/etc. that tracks memory and tells
you when you've been playing with uninitialized memory.  Search freshmeat
for that.

> And why wouldn't this seg fault yield a
> core dump? I can usually tell what is wrong when there's a core dump. 

The easy solution: ulimits.  Try issuing the command 'ulimit' at a prompt.
You'll get a list of (user/unix?) limits for various things; one of them
is coredumpsize.  Try a 'ulimit coredumpsize unlimited' and then run your
program.  Then you should be able to load the coredump into gdb - check
the docs; I have to every time I want to check a core.

Cheers,
--Mark

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).