Bug #546

panic: getblk: vnode 0xce889690 has no object!

Added by qhwt+dfly over 7 years ago. Updated almost 6 years ago.

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

0%

Category:-
Target version:-

Description

Hello.
I caught this panic while playing with firefox-2.0.0.1 (linux binary)
and flash9 plugin. The panic was triggered by /bin/ls (not
/compat/linux/bin/ls), after firefox crashed. I don't use any filesystems
other than ufs (not even /proc), yet the trace involves vop_compat_nresolve.

I did `fsck -fy' before this panic, so I believe this is not a panic-long-
after-an-incomplete-fsck problem.

Regards.

panic.gz (2.73 KB) qhwt+dfly, 01/28/2007 06:17 PM

History

#1 Updated by dillon over 7 years ago

:Hello.
:I caught this panic while playing with firefox-2.0.0.1 (linux binary)
:and flash9 plugin. The panic was triggered by /bin/ls (not
:/compat/linux/bin/ls), after firefox crashed. I don't use any filesystems
:other than ufs (not even /proc), yet the trace involves vop_compat_nresolve.
:
:I did `fsck -fy' before this panic, so I believe this is not a panic-long-
:after-an-incomplete-fsck problem.
:
:Regards.

Could you upload the coredump to leaf?

This panic occurs when a vnode has no associated VM object. VM objects
used to be optional but are now mandatory, so there must have been a
path where the vnode was created without a VM object (possibly before
the ls). Examining the vnode might give me a clue as to how that
happened.

-Matt

#2 Updated by qhwt+dfly over 7 years ago

Done, saved as ~y0netan1/crash/panic-11.tar.gz . The source code
is as of just before my last commit to /sys/dev/acpica5/acpi.c (rev 1.30).

Regards.

#3 Updated by dillon over 7 years ago

:...
:> :Regards.
:>
:> Could you upload the coredump to leaf?
:>
:> This panic occurs when a vnode has no associated VM object. VM objects
:> used to be optional but are now mandatory, so there must have been a
:> path where the vnode was created without a VM object (possibly before
:> the ls). Examining the vnode might give me a clue as to how that
:> happened.
:
:Done, saved as ~y0netan1/crash/panic-11.tar.gz . The source code
:is as of just before my last commit to /sys/dev/acpica5/acpi.c (rev 1.30).
:
:Regards.

Hmm. Something very odd is going on here. It is trying to resolve
the filename "firefox-2.0.0.1" at this path:

frame 9
print ap->a_nch->ncp->nc_name ("firefox-2.0.0.1")
print ap->a_nch->ncp->nc_parent->nc_name ("firefox")
print *ap->a_nch->mount ("/u")

So the path is:

"/u/firefox/firefox-2.0.0.1"

The problem is that /u/firefox seems to be a softlink. At least,
the vnode is marked as being a softlink and that makes the
namecache entry illegal because it must be a directory (the namecache
represents the 'real' path, not paths through softlinks).

The kernel then treats the vnode as a directory even though it is
a VLNK, tries to do a block lookup on it, and panics.

-Matt
Matthew Dillon
<>

#4 Updated by qhwt+dfly over 7 years ago

I need to look at the directory to make sure (it's not here with me now),
but I believe /u/firefox is a symlink which points to firefox-2.0.0.1,
and the link doesn't contain a slash; i.e. I did the following to create
the symlink:

# cd /u && ln -s firefox-2.0.0.1 firefox

I use "/u/firefox/firefox" to start this linux version. I don't use chroot
to use any linux binaries.

Regards.

#5 Updated by qhwt+dfly almost 6 years ago

I've been unable to reproduce this for more than a year,
and I think this was caused by leftover from kernel crash.

Also available in: Atom PDF