Bug #251

Panic on -current

Added by wa1ter about 8 years ago. Updated over 7 years ago.

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

0%

Category:-
Target version:-

Description

I updated world/kernel this morning and all seemed good until
I exited from my gnome X session. Here is what kgdb says:

(kgdb) bt
#0 lwkt_switch () at thread2.h:177
#1 0xc02e2384 in trap (frame=Error accessing memory address 0x8: Bad address.
) at /usr/src/sys/i386/i386/trap.c:349
Previous frame inner to this frame (corrupt stack?)

History

#1 Updated by dillon about 8 years ago

:I updated world/kernel this morning and all seemed good until
:I exited from my gnome X session. Here is what kgdb says:
:
:(kgdb) bt
:#0 lwkt_switch () at thread2.h:177
:#1 0xc02e2384 in trap (frame=Error accessing memory address 0x8: Bad address.
:) at /usr/src/sys/i386/i386/trap.c:349
:Previous frame inner to this frame (corrupt stack?)

Hmm. Upload the core, I might be able to salvage it.

Is it repeatable ?

-Matt
Matthew Dillon
<>

#2 Updated by wa1ter about 8 years ago

Matthew Dillon wrote:
> :I updated world/kernel this morning and all seemed good until
> :I exited from my gnome X session. Here is what kgdb says:
> :
> :(kgdb) bt
> :#0 lwkt_switch () at thread2.h:177
> :#1 0xc02e2384 in trap (frame=Error accessing memory address 0x8: Bad address.
> :) at /usr/src/sys/i386/i386/trap.c:349
> :Previous frame inner to this frame (corrupt stack?)
>
> Hmm. Upload the core, I might be able to salvage it.

It's in my crash directory on leaf.

> Is it repeatable ?

Definitely, but not immediately after a reboot -- I need to mess
around for awhile in an X session, and then exit from X.

#3 Updated by schlesinger about 8 years ago

Am Donnerstag, 20. Juli 2006 00:08 schrieb walt:
> I updated world/kernel this morning and all seemed good until
> I exited from my gnome X session. Here is what kgdb says:
>
> (kgdb) bt
> #0 lwkt_switch () at thread2.h:177
> #1 0xc02e2384 in trap (frame=Error accessing memory address 0x8: Bad
> address. ) at /usr/src/sys/i386/i386/trap.c:349
> Previous frame inner to this frame (corrupt stack?)

I've updated the kernel yesterday, too, and my machine rebooted while working
in a KDE session. Unfortunately, I do not have more informations. Maybe it's
the same as walt's problem.

Thomas

#4 Updated by dillon about 8 years ago

:It's in my crash directory on leaf.
:
:> Is it repeatable ?
:
:Definitely, but not immediately after a reboot -- I need to mess
:around for awhile in an X session, and then exit from X.

I need the kernel binary as well.

-Matt
Matthew Dillon
<>

#5 Updated by wa1ter about 8 years ago

On Thu, 20 Jul 2006, Matthew Dillon wrote:

>
> :It's in my crash directory on leaf.
> :
> :> Is it repeatable ?
> :
> :Definitely, but not immediately after a reboot -- I need to mess
> :around for awhile in an X session, and then exit from X.
>
> I need the kernel binary as well.

Done. I already deleted /var/crash/* so I sent /kernel instead.

#6 Updated by dillon about 8 years ago

:..
:> :
:> :Definitely, but not immediately after a reboot -- I need to mess
:> :around for awhile in an X session, and then exit from X.
:>
:> I need the kernel binary as well.
:
:Done. I already deleted /var/crash/* so I sent /kernel instead.

Fixed. My VOP vector cleanup indirected through a mount point without
checking to see if the vnode was dead or not.

-Matt
Matthew Dillon
<>

#7 Updated by schlesinger about 8 years ago

Am Donnerstag, 20. Juli 2006 16:24 schrieb Thomas Schlesinger:
> Am Donnerstag, 20. Juli 2006 00:08 schrieb walt:
> > I updated world/kernel this morning and all seemed good until
> > I exited from my gnome X session. Here is what kgdb says:
> >
> > (kgdb) bt
> > #0 lwkt_switch () at thread2.h:177
> > #1 0xc02e2384 in trap (frame=Error accessing memory address 0x8: Bad
> > address. ) at /usr/src/sys/i386/i386/trap.c:349
> > Previous frame inner to this frame (corrupt stack?)
>
> I've updated the kernel yesterday, too, and my machine rebooted while
> working in a KDE session. Unfortunately, I do not have more informations.
> Maybe it's the same as walt's problem.
>
> Thomas

I've had two more to sudden reboots, one after >5hrs of KDE usage and one
after a few minutes.

Thomas

#8 Updated by dillon about 8 years ago

:I've had two more to sudden reboots, one after >5hrs of KDE usage and one
:after a few minutes.
:
:Thomas

Try HEAD as of today. I committed a fix a little earlier in the day.

-Matt
Matthew Dillon
<>

#9 Updated by corecode almost 8 years ago

Is this fixed?

#10 Updated by wa1ter almost 8 years ago

Simon 'corecode' Schubert wrote:
> Simon 'corecode' Schubert <> added the comment:
>
> Is this fixed?
>
> _______________________________________________________
> DragonFly issue tracker <>
> <http://bugs.dragonflybsd.org/issue251>
> _______________________________________________________

Yes. I should mention that I posted a different bug with
the same title on 9-23-2006 which is not yet fixed.

#11 Updated by dillon almost 8 years ago

:Yes. I should mention that I posted a different bug with
:the same title on 9-23-2006 which is not yet fixed.

I'll get the second one fixed right now. I see your core on leaf.

-Matt
Matthew Dillon
<>

#12 Updated by dillon almost 8 years ago

It crashed on a NULL pointer indirection trying to mmap() ucanner0.

Do you have a USB scanner connected? I can do a NULL check easily
enough but it should not have been able to open a descriptor in the
first place if there was no scanner. Or, if there was a scanner,
maybe it got unplugged at some point before the mmap (though that
shouldn't have NULLed out the field either).

-Matt
Matthew Dillon
<>

#13 Updated by dillon almost 8 years ago

I think the descriptor might have gotten revoked with revoke(). Since
it is a VCHR device, that would have succeeded. But mmap() doesn't
have the correct check for a revoked device descriptor so I will go
ahead and add the check.

-Matt
Matthew Dillon
<>

#14 Updated by wa1ter almost 8 years ago

Yes, there is a USB scanner plugged in, and I never unplugged it.

What is a VCHR device?

#15 Updated by dillon almost 8 years ago

:Yes, there is a USB scanner plugged in, and I never unplugged it.
:
:What is a VCHR device?

Its just the #define used to identify a CHR device, which is
basically everything in /dev.

In anycase, the latest HEAD should fix the issue. I'm guessing
that one of those GUI programs is revoke()ing access to the
device while another one has an open descriptor to it and then
tries to mmap() it.

-Matt
Matthew Dillon
<>

Also available in: Atom PDF