(Illustration by Gaich Muramatsu)
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. > > JanReceived on 2000-06-06 18:34:23