Jan Harkes <[EMAIL PROTECTED]> writes:
> On Mon, May 21, 2001 at 03:33:33PM +0200, Steffen Neumann wrote:
[...]
> > cat /tmp/gdb.trace
> > #0 0x80764e9 in namectxt::printsuspect (this=0x9161798, fd=12, verbosity=0) at
>hdb.cc:2472
> ...
> > #15 0x8076629 in namectxt::printsuspect (this=0x94fe600, fd=12, verbosity=0) at
>hdb.cc:2505
> > #16 0x8074731 in hdbent::printsuspect (this=0x2507fa88, afd=12, verbosity=0) at
>hdb.cc:1394
>
>
> Ok, we recursed 16 deep into namectxt::printsuspect, each of which puts
[...]
> by using up over 64KB of stackspace.
[...]
> Quick patch that leaves the recursion, but significantly lowers the
> stack usage is attached. (I have only tested that it compiles)
Well, it does compile. Nevertheless, the problem remains,
with the same depth of recursion than before.
Anything else I can check ?
Yours,
Steffen
-----------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x8074ea9 in namectxt::printsuspect (this=0x8a9acb8, fd=12, verbosity=0) at hdb.cc:2445
(gdb) where
#0 0x8074ea9 in namectxt::printsuspect (this=0x8a9acb8, fd=12, verbosity=0) at
hdb.cc:2445
#1 0x8074fe9 in namectxt::printsuspect (this=0x876d0d0, fd=12, verbosity=0) at
hdb.cc:2478
#2 0x8074fe9 in namectxt::printsuspect (this=0x9072d80, fd=12, verbosity=0) at
hdb.cc:2478
#3 0x8074fe9 in namectxt::printsuspect (this=0x8aeda60, fd=12, verbosity=0) at
hdb.cc:2478
#4 0x8074fe9 in namectxt::printsuspect (this=0x849e948, fd=12, verbosity=0) at
hdb.cc:2478
#5 0x8074fe9 in namectxt::printsuspect (this=0x913deb0, fd=12, verbosity=0) at
hdb.cc:2478
#6 0x8074fe9 in namectxt::printsuspect (this=0x9516730, fd=12, verbosity=0) at
hdb.cc:2478
#7 0x8074fe9 in namectxt::printsuspect (this=0x8309058, fd=12, verbosity=0) at
hdb.cc:2478
#8 0x8074fe9 in namectxt::printsuspect (this=0x91cb628, fd=12, verbosity=0) at
hdb.cc:2478
#9 0x8074fe9 in namectxt::printsuspect (this=0x94210a8, fd=12, verbosity=0) at
hdb.cc:2478
#10 0x8074fe9 in namectxt::printsuspect (this=0x83695c8, fd=12, verbosity=0) at
hdb.cc:2478
#11 0x8074fe9 in namectxt::printsuspect (this=0x8fb3f50, fd=12, verbosity=0) at
hdb.cc:2478
#12 0x8074fe9 in namectxt::printsuspect (this=0x83991e8, fd=12, verbosity=0) at
hdb.cc:2478
#13 0x8074fe9 in namectxt::printsuspect (this=0x8385348, fd=12, verbosity=0) at
hdb.cc:2478
#14 0x8074fe9 in namectxt::printsuspect (this=0x9522c10, fd=12, verbosity=0) at
hdb.cc:2478
#15 0x8074fe9 in namectxt::printsuspect (this=0x9502600, fd=12, verbosity=0) at
hdb.cc:2478
#16 0x8073051 in hdbent::printsuspect (this=0x2507b748, afd=12, verbosity=0) at
hdb.cc:1394
#17 0x8072946 in hdb::Verify (this=0x25089d48, m=0x94ea394, local_id=10157) at
hdb.cc:1225
#18 0x80756ae in HDBD_HandleRequests () at hdb_daemon.cc:207
#19 0x8075269 in HDBDaemon () at hdb_daemon.cc:115
#20 0x80a8285 in vproc::main (this=0x94e4ae8) at vproc.cc:429
#21 0x80a7a72 in VprocPreamble (init_lock=0x94e4b28) at vproc.cc:146
#22 0x4008d2d0 in Create_Process_Part2 () at lwp.c:792
2445 void namectxt::printsuspect(int fd, int verbosity) {
2446 /* verbosity = 0 silence except for errors
2447 0 < verbosity <= 100 errors and confirmation of items in hoard
database
2448 100 < verbosity errors and confirmation of all expanded items
2449 */
2450 char fullpath[MAXPATHLEN+1];
2451 const char *modifier = expand_descendents ? "d+" :
2452 (expand_children ? "c+" : " ");
2453
2454 /* Deal with this node first */
2455 dlink *d = expansion.last();
2456 if (d == 0){
2457 PUTMSG("*** Not bound ***", 1);
2458 return;
2459 }
...
2470 if (verbosity) PUTMSG("OK", 0);
2471
2472 /* Then recursively deal with children */
2473 if (children) {
2474 dlist_iterator cnext(*children);
2475 dlink *d;
2476 while ((d = cnext())) {
2477 namectxt *child = strbase(namectxt, d, child_link);
2478 child->printsuspect(fd, ((verbosity > 100) ? verbosity : 0));
2479 }
2480 }
2481 }
2482 #undef PUTMSG
