DragonFlyBSD

: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 
                    <dillon@backplane.com>

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.

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

: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 
                    <dillon@backplane.com>

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.

:..
:> :
:> :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 
                    <dillon@backplane.com>

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

: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 
                    <dillon@backplane.com>

Is this fixed?

Simon 'corecode' Schubert wrote:

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> added the comment:

Is this fixed?

_______________________________________________
DragonFly issue tracker <issues@chlamydia.fs.ei.tum.de>
<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.

: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 
                    <dillon@backplane.com>

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 
                    <dillon@backplane.com>

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 
                    <dillon@backplane.com>

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

What is a VCHR device?

: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 
                    <dillon@backplane.com>