On Tue, Feb 20, 2001 at 11:08:14PM +0100, Eric Thomas wrote:
> > (gdb) where
> > #0  0x2817972a in ?? ()
> > #1  0x281858e3 in ?? ()
> > #2  0x8057660 in LSV_sprintf ()
> > #3  0x80c0434 in LSWSETEP ()
> > #4  0x804fdfd in LSWCMDCL ()
> > #5  0x8072c8c in LSWCMD ()
> > #6  0x8096c6b in LSWJCMD ()
> > #7  0x80bad22 in LSWRDR ()
> > #8  0x80b4f91 in Process ()
> > #9  0x80b5918 in LSWPRFGO ()
> > #10 0x80600d2 in Go ()
> > #11 0x8060123 in main ()
>
> Unix core dumps are almost always due to insufficient virtual memory
> quotas (either the quotas themselves or something that needs to be
> increased in order to allow quotas to be actually increased, for instance
> swap space or kernel parameters), but in the present case I think it
> could be something else. There ought to be a SET command at the
> tail of the log when this happens, and it ought to crash the server
> whenever issued. Perhaps the list in question is corrupted.

Thanks for the reply.  How do I go about determining which list
might be corrupt?  Can you give me an example of a command that
might trigger a crash resulting in a coredump like above?  I'd
be very happy to get to the bottom of this one, if you could
give me some guidance on what to try and what to look for.  Thanks.

I'm a little confused by one of your remarks above.  There is a
known sequence that is supposed to (read by design) crash the server?
Wouldn't that be considered a Bad Thing (tm)?  IMHO deliberately
crashing a long-running daemon should only be resorted to when
there is absolutely no way to recover.  Which in this case might
be true.  However, being a software dude myself it would be nice
to understand why this extreme measure would be required.  If
nothing else knowing which sequence triggers it would be nice so
I can avoid it at all costs.

-Steve