Bug #983

Panic in a vkernel: getblk: vnode 0x669232e8 has no object!

Added by rumcic over 6 years ago. Updated about 3 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

While compiling kde inside a vkernel a panic occured. The vkernel should be
from the latest source while the real kernel is from about Feb 7 (well there
is a possibility that the real kernel is too old right?).

Making all in kio
panic: getblk: vnode 0x669232e8 has no object!
Trace beginning at frame 0x672d4870
panic(672d4894,206d5938,669232e8,669232e8,672d48b8) at 0x80a1767
panic(81d7f84,669232e8,0,672d48cc,63be2ca8) at 0x80a1767
getblk(669232e8,fbfc8000,ffffffbf,4000,0) at 0x80d996e
ffs_balloc(ffffffff,2,672d4974,0,0) at 0x818b5ac
ffs_truncate(669232e8,0,0,0,0) at 0x818c215
ufs_inactive(672d4a58,672d4a74,80f001e,672d4a58,8209db0) at 0x81969b7
ufs_vnoperate(672d4a58,8209db0,5ee91fd0,66964418,0) at 0x8199569
vop_inactive(5ee91fd0,669232e8,669232f8,672d4a9c,808260a) at 0x80f001e
vget(669232e8,672d4b1c,669232f8,672d4ab0,80e7e97) at 0x80e803b
_sysref_put(669232f8,672d4b5c,66964418,672d4af8,80df8a0) at 0x808260a
vrele(669232e8,672d4b5c,669232e8,66580228,0) at 0x80e7e97
vop_compat_nresolve(672d4b1c,672d4b10,8199569,672d4b1c,672d4b40) at 0x80df8a0
vop_defaultop(672d4b1c,672d4b40,80f0323,672d4b1c,8209e40) at 0x80df3eb
ufs_vnoperate(672d4b1c,8209e40,5ee91fd0,672d4b94,66964418) at 0x8199569
vop_nresolve(5ee91fd0,672d4b5c,66580228,63b08878,63b67b60) at 0x80f0323
cache_resolve(672d4b8c,63b08878,672d4c38,0,672d4c38) at 0x80dc678
nlookup(672d4c38,0,672d4c38,672d4ca0,672d4c78) at 0x80e3e6d
kern_stat(672d4c38,672d4bd0,1,672d4c2c,bfbff000) at 0x80eba9f
sys_lstat(672d4ca0,6,0,0,671fb740) at 0x80ebb47
syscall2(672d4d40,2,6,0,0) at 0x81bd64f
user_trap(672d4d40,620cc700,81bd451,0,81bdcec) at 0x81bd822
go_user(672d4d38,0,0,7b,0) at 0x81bdba1
Debugger("panic")
Stopped at 0x81bb269: movb $0,0x82a08d4

P.S.: I still have no idea how to get a coredump of a vkernel (it's currently
in the debugger and I'll leave it like that for now), so how would I get more
usable info/dump?
--
Regards,
Rumko

History

#1 Updated by nant over 6 years ago

Can the memory image file be used as a core dump?

Cheers,
Nuno

#2 Updated by rumcic over 6 years ago

Hm:
"/home/var.vkernel/memimg.000000" is not a core dump: File format not
recognized" guess not? (tried it with gdb not kgdb)

#3 Updated by nthery over 6 years ago

I'm afraid there is no way to capture vkernel core dumps currently.
Simon posted a debug-oriented wish list a while ago and, IIRC, vkernel
core dumps were part of it.

#4 Updated by nthery over 6 years ago

I wonder how _sysref_put() can end up calling vget(). Any idea?

#5 Updated by dillon over 6 years ago

:Hm:
:"/home/var.vkernel/memimg.000000" is not a core dump: File format not
:recognized" guess not? (tried it with gdb not kgdb)

Heh. No but you CAN gdb the live vkernel (assuming it dropped into
db> it is still running).

In anycase, don't bother going that far. There's definitely a bug
here. The vnode is supposed to have a VM object associated with it
and clearly there must be a path where that vnode can be instantiated
without one.

Can you by any chance reproduce the bug to test that this patch
fixes the problem?

-Matt

Index: ufs_inode.c
===================================================================
RCS file: /cvs/src/sys/vfs/ufs/ufs_inode.c,v
retrieving revision 1.24
diff -u -p -r1.24 ufs_inode.c
--- ufs_inode.c 2 Jan 2008 22:42:37 -0000 1.24
+++ ufs_inode.c 2 Apr 2008 05:51:41 -0000
@@ -87,6 +87,8 @@ if (!ufs_getinoquota(ip))
(void)ufs_chkiq(ip, -1, NOCRED, FORCE);
#endif
/* Must have a VM object to truncate */
+ if (vp->v_object == NULL)
+ vinitvmio(vp, 0);
error = ffs_truncate(vp, (off_t)0, 0, NOCRED);
ip->i_rdev = 0;
mode = ip->i_mode;

#6 Updated by dillon over 6 years ago

:
:2008/4/1, Rumko <>:
:> vget(669232e8,672d4b1c,669232f8,672d4ab0,80e7e97) at 0x80e803b
:> _sysref_put(669232f8,672d4b5c,66964418,672d4af8,80df8a0) at 0x808260a
:
:I wonder how _sysref_put() can end up calling vget(). Any idea?

I think that's just a backtrace snafu. The vkernrel's DDB support
for backtraces is rather hacked up.

-Matt
Matthew Dillon
<>

#7 Updated by rumcic over 6 years ago

Matthew Dillon wrote:

I'll try to reproduce it, but since this is the first time I got this panic ...
I'll see if it can be done
--
Regards,
Rumko

#8 Updated by dillon over 6 years ago

:> /* Must have a VM object to truncate */
:> + if (vp->v_object == NULL)
:> + vinitvmio(vp, 0);
:> error = ffs_truncate(vp, (off_t)0, 0, NOCRED);
:> ip->i_rdev = 0;
:> mode = ip->i_mode;
:
:I'll try to reproduce it, but since this is the first time I got this panic ...
:I'll see if it can be done
:--
:Regards,
:Rumko

Scrap that patch. It's bad. It causes more panics then it fixes.

-Matt
Matthew Dillon
<>

#9 Updated by rumcic over 6 years ago

Matthew Dillon wrote:

Ok ... I have yet to reproduce the panic (the vkernel is still building the
packages) so I have not applied the patch yet.
--
Regards,
Rumko

#10 Updated by rumcic over 6 years ago

Rumko wrote:

Alrighty ... I triggered another panic (while checking out the pkgsrc tree ...
but it seems to me a different panic unrelated to this?

Checkout latest pkgsrc-current...
mode = 030721, inum = 64, fs =
panic: ffs_valloc: dup alloc
Trace beginning at frame 0x6565480c
panic(65654830,0,58583800,65c95300,656548ac) at 0x80a1777
panic(81ebe10,81eba88,31d1,40,585838d4) at 0x80a1777
ffs_valloc(65c27de8,81a4,63b08798,656548d0,65654bbc) at 0x81888fd
ufs_vnoperatespec(65654a60,fffffffe,65ca7c08,65654a08,81996cd) at 0x8199e28
ufs_vnoperatespec(65654a14,65654a3c,80efc2c,65654a14,820a370) at 0x819a11b
ufs_vnoperate(65654a14,820a370,5ee91fd0,2,65c27de8) at 0x81996cd
vop_old_create(5ee91fd0,65c27de8,65654bbc,65654a60,65654b10) at 0x80efc2c
vop_compat_ncreate(65654ab0,65654aa4,81996cd,65654ab0,65654ae4) at 0x80e05cd
vop_defaultop(65654ab0,65654ae4,80f09a3,65654ab0,820a4d0) at 0x80df3ef
ufs_vnoperate(65654ab0,820a4d0,5ee91fd0,6216700f,0) at 0x81996cd
vop_ncreate(5ee91fd0,65654c38,65c27de8,65654bbc,63b08798) at 0x80f09a3
vn_open(65654c38,63bc8778,20a,1a4,620c9400) at 0x80ef076
kern_open(65654c38,209,1b6,65654ca0,65ca7c08) at 0x80ec5ba
sys_open(65654ca0,6,0,0,63b2ed18) at 0x80ec78f
syscall2(65654d40,0,6,0,0) at 0x81bd7af
user_trap(65654d40,620c9400,81bd5b1,0,81bde4c) at 0x81bd982
go_user(65654d38,0,0,7b,0) at 0x81bdd01
Debugger("panic")
Stopped at 0x81bb3c9: movb $0,0x82a1074
--
Regards,
Rumko

#11 Updated by dillon over 6 years ago

:Alrighty ... I triggered another panic (while checking out the pkgsrc tree ...
:but it seems to me a different panic unrelated to this?
:
:Checkout latest pkgsrc-current...
:mode = 030721, inum = 64, fs =
:panic: ffs_valloc: dup alloc
:Trace beginning at frame 0x6565480c

That's a different, unrealted panic.

Did you at any time prior to the checkout fill up the filesystem?
There's a bug in UFS that can cause corruption when the filesystem
fills up which we haven't patched yet.

-Matt

#12 Updated by rumcic over 6 years ago

Matthew Dillon wrote:

Er ... now that is a very good question ... I don't remember right now if I did
ever fill it up, but the base image which I copy (and abuse the copy) is very
old, so there is a possibility of that ... oh well, guess it's time to remake
the base image.
--
Regards,
Rumko

#13 Updated by rumcic over 6 years ago

Well it's been a long time, but I have managed to get a panic with "panic:
getblk: vnode 0xf1fda768 has no object!" on my host machine this time.
The kernel.1 and vmcore.1 files are at leaf:~rumko/crash/01.05.2008

The backtrace:
#0 dumpsys () at ./machine/thread.h:83
#1 0xc0270739 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:375
#2 0xc02709fc in panic (fmt=0xc050659c "getblk: vnode %p has no object!") at
/usr/src/sys/kern/kern_shutdown.c:800
#3 0xc02ac5c6 in getblk (vp=0xf1fda768, loffset=-274945245184, size=16384,
blkflags=<value optimized out>, slptimeo=0)
at /usr/src/sys/kern/vfs_bio.c:2350
#4 0xc03b0160 in ffs_indirtrunc (ip=0xf1389200, lbn=-16781326, dbn=-16793008,
lastbn=-1, level=2, countp=0xf18629c0)
at /usr/src/sys/vfs/ufs/ffs_inode.c:465
#5 0xc03b0da5 in ffs_truncate (vp=0xf1fda768, length=0, flags=0, cred=0x0) at
/usr/src/sys/vfs/ufs/ffs_inode.c:333
#6 0xc03bb472 in ufs_inactive (ap=0xf1862aa4) at
/usr/src/sys/vfs/ufs/ufs_inode.c:90
#7 0xc03bdffa in ufs_vnoperate (ap=0xf1862aa4) at
/usr/src/sys/vfs/ufs/ufs_vnops.c:2444
#8 0xc02c2e56 in vop_inactive (ops=0xd3a14970, vp=0xf1fda768) at
/usr/src/sys/kern/vfs_vopops.c:610
#9 0xc02badc8 in vnode_terminate (vp=0xf1fda768) at
/usr/src/sys/kern/vfs_lock.c:252
#10 0xc0250670 in _sysref_put (sr=0xf1fda778) at /usr/src/sys/kern/kern_sysref.c:318
#11 0xc02bac20 in vrele (vp=0x0) at /usr/src/sys/sys/sysref2.h:85
#12 0xc02b25f0 in vop_compat_nresolve (ap=0xf1862b68) at
/usr/src/sys/kern/vfs_default.c:230
#13 0xc02b213b in vop_defaultop (ap=0xf1862b68) at
/usr/src/sys/kern/vfs_default.c:146
#14 0xc03bdffa in ufs_vnoperate (ap=0xf1862b68) at
/usr/src/sys/vfs/ufs/ufs_vnops.c:2444
#15 0xc02c315b in vop_nresolve (ops=0xd3a14970, nch=0xf1862ba8, dvp=0xf2331168,
cred=0xe0b53318)
at /usr/src/sys/kern/vfs_vopops.c:945
#16 0xc02af3be in cache_resolve (nch=0xf1862bd8, cred=0xe0b53318) at
/usr/src/sys/kern/vfs_cache.c:2065
#17 0xc02b6bc4 in nlookup (nd=0xf1862c84) at /usr/src/sys/kern/vfs_nlookup.c:397
#18 0xc02be82f in kern_stat (nd=0xf1862c84, st=0xf1862c1c) at
/usr/src/sys/kern/vfs_syscalls.c:2157
#19 0xc02be8d7 in sys_lstat (uap=0xf1862cf0) at
/usr/src/sys/kern/vfs_syscalls.c:2220
#20 0xc048132d in syscall2 (frame=0xf1862d40) at
/usr/src/sys/platform/pc32/i386/trap.c:1348
#21 0xc046e8b5 in Xint0x80_syscall () at
/usr/src/sys/platform/pc32/i386/exception.s:872
#22 0x0804e698 in ?? ()

#14 Updated by tuxillo over 5 years ago

Matt, if I recall correctly you managed to buildworld and buildkernel inside a
vkernel, right?

#15 Updated by rumcic about 3 years ago

  • Description updated (diff)
  • Status changed from New to Closed

Been a long time since I was able to make a panic like this, consider resolved for now

Also available in: Atom PDF