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
