From: Terry R. Friedrichsen (terry_at_venus.sunquest.com)
Date: Fri Mar 17 2000 - 01:20:37 GMT
> 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? I didn't send that message to the list, though I probably should have ... I had pointed out that running the infinite-recursion program under either FreeBSD or Linux (not under UPS) created a core file which gdb(1) had no trouble interpreting. It did, in fact, report meaningfully about the call stack. Regrettably, I did not, at the time, actually run the program under gdb - I'll hafta give that a try. The point I was making was just that infinite recursion does *not* corrupt the call stack - it simply fills it up (and rather rapidly, too :-). In any case, running the infinite recursion program either under UPS or not eventually causes a malloc() failure in e_malloc(), at least in my case. Clearly, some sort of process or system memory limit is being exceeded. UPS could possibly be coded to be more helpful about this, per- haps by doing something like reporting the call stack depth on termination or when reading a core file or by reporting how many times the routine at the top of the call stack repeats immediately underneath on the stack. Someone else will doubtless have more clever ideas. Terry R. Friedrichsen terry_at_venus.sunquest.com
This archive was generated by hypermail 2.1.4 : Wed Feb 13 2002 - 21:51:33 GMT