On Mon, Oct 04, 1999 at 02:24:44AM +0200, Clemens Oertel wrote:
> > When an assertion fails a server actually goes into an endless sleep,
> > and it is possible to use a debugger (gdb) to grab a stacktrace and find
> > out why it died. 
> 
> Unfortunately, I'm not that good at debugging c/c++ coda, so I have to
> admit that the gdb wasn't much help. It complained about a not
> accessible address 0x4 or told me something about 0x0 in ??

Did you try:

gdb /usr/sbin/codasrv `pidof codasrv`
gdb> bt
...
...
...

There should be some interesting information like function names, except
if the debugging symbols got stripped from the binary.

> I also tried a couple makevldb's and makevrdb's, but, as you might have
> guessed, no luck.

Well, actually occasionally that does help.

> The funny thing is: The server starts, I can access the temporary root
> volume, mount the former root volume, I even get one or two 'ls', but
> when I try to access a file or just wait a couple of minutes, the server
> crashes with the VSG not found message.

Interesting, that might indicate that the VRList, from which the VRDB is
derived is bad, it's lines should have enough 0's in them.

vmm:root 7F00049A 3 c9000082 dd000085 c7000085 0 0 0 0 0 E0000203
                  ^
	    # of replicas
			^       ^        ^
			replica id's
					       ^ ^ ^ ^ ^
						# of replicas + 0's
						should add up to 8

							    ^
							Should match an
							entry in the VSGDB

If there is a bad line, the created VRDB could be the cause of the
problems you describe.

After fixing the VRList, run `volutil makevrdb /vice/vol/VRList` to
recreate the VRDB.

Jan