Project

General

Profile

Actions

Bug #251

closed

Panic on -current

Added by wa1ter over 17 years ago. Updated over 17 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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?)

Actions #1

Updated by dillon over 17 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
<>
Actions #2

Updated by wa1ter over 17 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.

Actions #3

Updated by schlesinger over 17 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

Actions #4

Updated by dillon over 17 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
<>
Actions #5

Updated by wa1ter over 17 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.

Actions #6

Updated by dillon over 17 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
<>
Actions #7

Updated by schlesinger over 17 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

Actions #8

Updated by dillon over 17 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
<>
Actions #9

Updated by corecode over 17 years ago

Is this fixed?

Actions #10

Updated by wa1ter over 17 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.

Actions #11

Updated by dillon over 17 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
&lt;&gt;
Actions #12

Updated by dillon over 17 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
&lt;&gt;
Actions #13

Updated by dillon over 17 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
&lt;&gt;
Actions #14

Updated by wa1ter over 17 years ago

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

What is a VCHR device?

Actions #15

Updated by dillon over 17 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
&lt;&gt;
Actions

Also available in: Atom PDF