On Saturday, 31 July 1999 at 0:19:27 +0200, Jeroen Ruigrok/Asmodai wrote:
> * Greg Lehey ([EMAIL PROTECTED]) [990730 11:23]:
>> On Friday, 30 July 1999 at 8:45:32 +0200, Jeroen Ruigrok/Asmodai wrote:
>
>>> I started a make world on my box last night and then proceeded to go to bed.
>>>
>>> When I looked at my console this morning it had sprung into DDB because
>>> of a panic: ffs_alloccg: map corrupted.
>>
>> The first question is: do you have a kernel with debug symbols? If
>> not, gdb isn't going to help you much. bde can do it with ddb (though
>> it's a bit late if you have the dump), but mere mortals are in trouble
>> without symbols.
>
> I thought I had one, but alas I didn't. *sigh* One of those days when ye
> bump against stuff you should've done. Learned from that in a multiple
> ways, so next time I got everything I need...
That's why I tried a few months back to make debug symbols the
default.
>> The first thing you should do with any dump is a backtrace (bt). The
>> appearance depends on how you got there. Since you appear to have
>> gone via ddb, your dump should look something like this:
>
> Here is at least some info:
>
> (kgdb) bt
> #0 0xc0155f14 in boot ()
> #1 0xc0156249 in panic ()
> #2 0xc01e737b in ffs_mapsearch ()
> #3 0xc01e5cea in ffs_alloccg ()
> #4 0xc01e5756 in ffs_hashalloc ()
> #5 0xc01e4adc in ffs_alloc ()
> #6 0xc01e7af0 in ffs_balloc ()
> #7 0xc01f0a5c in ffs_write ()
> #8 0xc01827ce in vn_write ()
> #9 0xc01623ac in dofilewrite ()
> #10 0xc01622bb in write ()
> #11 0xc0225066 in syscall ()
> #12 0xc02192b6 in Xint0x80_syscall ()
> #13 0x807d24a in ?? ()
> #14 0x807666d in ?? ()
Hmm, that doesn't look like a dump from ddb. Did you have
DDB_UNATTENDED set?
> Think I'll read up on GDB in my printed manual...
>
> Other hints/tips still welcome, I still have the dumps =)
OK, you have the stack frame. The panic name appears wrong; it's out
of ffs_mapsearch, not ffs_alloccg. Anyway, ffs_mapsearch looks like
this:
static ufs_daddr_t
ffs_mapsearch(fs, cgp, bpref, allocsiz)
register struct fs *fs;
register struct cg *cgp;
ufs_daddr_t bpref;
int allocsiz;
{
ufs_daddr_t bno;
int start, len, loc, i;
int blk, field, subfield, pos;
At a first glance, it would seem that what you want to look at is
*cgp, which is stored at a fixed location from the stack frame
(%ebp+0xc). You could enter something like
(kgdb) f 2
(kgdb) x/30x *(int*)($ebp+0xc)
This should give you the first 30 ints of the cylinder group. If you
had symbols, this would be quite a bit simpler:
(kgdb) p *cgp
What you do with the results depends a lot on what you find. On the
whole, I wouldn't think it worth the pain of debugging without
symbols.
Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
