On Tue, 06 Jun 2000, Jan Harkes scribbled:
> On Mon, May 29, 2000 at 05:34:56PM -0400, Uriah wrote:
> > Hmm, looks familiar.  Im starting from source (compiling using egcs-2.91.66)
> > and getting simular results.  I thought that it was a problem with egcs and im
> > compiling gcc-2.95.2 to see if that will make a difference.  Did you notice a
> > simular error in .../etc/console?

gcc 2.95.2 didnt seam to like the coda source tree.   I tried the binary RPM's
and they had the same kind of symptoms.  Perhaps something in or expected to be
in SuSE is causing a problem? 

> > The following pointers should be between 21000000 and 21a1c000:
> > Ptrs = [21a1a888 21a1be48 21a1bfc8 2184ac48 0 21a1abc8],
>                                              ^^^
>
> The LRDB pointer in RVM is not correct. This should never happen, but it
> might be related to a not entirely successful startup in the previous
> run.

The first start up and any "venus -init" would check itself, catch a SIG10 and
quietly hang for GDB. If killed and restarted it would give a meaningfull
printout in console.

> 
> > UUID = c2a34a36-0000-0000-0000-000000000000
> 
> We really should start using libuuid or something. This way the UUIDs
> are not really universally unique ;)
> 
> > 11:55:40 fatal error -- Recov_InitSeg: rvg validation failed,
> >          restart venus with -init
> 
> So did you try the advice given here?

Yep, but venus literaly hangs with the -init flag.

> 
> > If I did start up gdb, what would one look for?
> 
> It depends on the situation, in this case there is plenty of useful
> information in the log, but in some cases the logs just don't have
> enough. Especially on `random' errors such as SIGSEGV or SIGBUS. As we
> map several 10's to 100's of megabytes, especially on servers, we spin
> the crashed apps in an endless loop to avoid filling the disk with huge
> core-dumps.
> 
> Jan