From: Bob Carragher (bob_at_fla.fujitsu.com)
Date: Thu Mar 16 2000 - 23:22:47 GMT
Okay, let's see if I understand what's happening here.
Let's say we have the following simple program:
recurse(int x) {
recurse(x+1);
}
main() {
recurse(0);
}
This should eventually die due to "infinite recursion."
When it dies, it does so because it is trying to grow
the stack beyond either system or memory limitations,
and so a segmentation fault occurs. At that point, a
SIGSEGV signal is generated. If a debugger is not
attached to the process, then a core file is generated.
Otherwise, if the debugger is set to catch that signal,
then control will transfer to the debugger. What happens
at this point may depend on the debugger, so I'll just
consider the case of UPS. In any case, the call stack
itself has not been "trashed."
In the case of UPS, it needs to allocate some sort of
data structure for each call frame. Solaris has an 8MB
maximum call stack size (as, I think, Dave Hayden mentioned
in another message), so with this program, we could have
well over 1 million call frames on the stack. I have no
idea how large each of these "call frame" data structures
that UPS allocates is, but let's say that it is under
500 bytes, at least in the case of this simple program.
I would assume that to be reasonable. So then UPS should
try to allocate some 500 MB, probably more, to handle the
call stack. My system has 1 GB of RAM and about 3 GB of
swap space. This should not pose a problem. So I don't
think I can fully buy the argument that UPS is running
out of allocateable system memory, unless one of my
assumptions is wrong, and seriously wrong at that. Any
ideas on what the problem might be? In the case of the
above program, UPS provides only the following information
in the display area:
Functions
<bad frame pointer 0xef7fff48>
recurse (no line numbers)
------------- SIGSEGV -------------
UPS itself didn't die. I could restart the debugger (and
the program itself) with no problem. I could even examine
the local variables of function "recurse" itself, although
that wasn't a very useful exercise.
I'm curious about Terry Friedrichsen's note that "gdb(1)
had no trouble with the core file." So should I take this
to mean that it was able to report meaningfully about the
contents of the call stack, even when you started the
program under gdb?
By the way, Ian Edward's suggestion of using Purify is
practically useful, but it doesn't help with proseletizing
UPS. B-) Also, Dave Hayden's suggestion of just using the
Stop button works just as well with any other debugger
(although it doesn't work in my test program's case, since
the stack blows up too quickly). B-)
Bob
This archive was generated by hypermail 2.1.4 : Wed Feb 13 2002 - 21:51:33 GMT