Named dying

[Adrian Daminato]

It appears to always die in the same place - which is something I hadn't
noticed before with the trace debugging

(from gdb)

#0  0x400786ad in __libc_close ()
#1  0x805f7ff in sq_remove (qp=0x40939008) at ns_main.c:1675
#2  0x805e224 in stream_getlen (lev={opaque = 0x80cbbc0}, uap=0x40939008,
    fd=7, bytes=0) at ns_main.c:852
#3  0x8085558 in __evDispatch (opaqueCtx={opaque = 0x80cbbc0}, opaqueEv={
      opaque = 0x400b638c}) at eventlib.c:497
#4  0x805d7d5 in main (argc=1, argv=0xbffffd78, envp=0xbffffd7c)
    at ns_main.c:514

Right after I quit gdb, let the program still run, and send the signals again,
it starts up again.

I'm not a whiz programmer or anything, and I don't see why it would stop
responding at __libc_close ()



On Fri, 18 Jun 1999, Paul Vixie wrote:
> is it consuming cpu time, or sitting idle?
> 
> if you "kill -SEGV" the pid, where does the core file's stacktrace say it is?
> (or if you have /proc, you can just attach to it from gdb and not -SEGV it.)
> -- 
> Paul Vixie <vixie at mibh.net>
> 
> "I sorta lean towards different both." --asp
--
Adrian Daminato 
Tucows International Corp.