DragonFlyBSD

:Connected to a vkernel running on leaf with gdb; when I detached, the vkernel
:was killed with SIGILL.
:
:PC is marked with , per core dump. Kernel and core are in leaf:~vsrinivas/ill.
:
:...
:0x08266e56 <kern_trap+5>: push %ebx
:0x08266e57 <kern_trap+6>: sub $0x14,%esp
:0x08266e5a <kern_trap+9>: mov 0x8(%ebp),%edi
:0x08266e5d <kern_trap+12>: mov %fs:0x0,%ebx
:***0x08266e64 <kern_trap+19>: mov 0x4(%ebx),%esi
:0x08266e67 <kern_trap+22>: mov 0x64(%esi),%eax

This is probably one of the I/O threads used by if_vke and if_vkd.
    These threads are not counted as 'cpus' and do not have globaldata
    structures.  They aren't supposed to fault at all and if they do the
    trap code will wind up being called, attempt to access the non-existant
    globaldata structure, and the vkernel will die with SIGILL.

So the question now is what smushed the vke/vkd I/O driver in the
    I/O thread when you detached?

-Matt

: This is probably one of the I/O threads used by if_vke and if_vkd.
: These threads are not counted as 'cpus' and do not have globaldata

Ah, I think it must be the I/O thread taking a signal due to the GDB
    interactions.  Those I/O threads absolutely cannot take signals, they
    will explode (the signals assume a globaldata context).

I'm not sure how we can address this.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On Sat, Sep 18, 2010 at 2:10 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:

:    This is probably one of the I/O threads used by if_vke and if_vkd.
:    These threads are not counted as 'cpus' and do not have globaldata

   Ah, I think it must be the I/O thread taking a signal due to the GDB
   interactions.  Those I/O threads absolutely cannot take signals, they
   will explode (the signals assume a globaldata context).

   I'm not sure how we can address this.

                                       -Matt
                                       Matthew Dillon
                                       <dillon@backplane.com>

Is it plausible to give all threads which don't have a real globaldata
context a shared fake globaldata context which the signal delivery
could check against?

Sam

:Is it plausible to give all threads which don't have a real globaldata
:context a shared fake globaldata context which the signal delivery
:could check against?
:
:Sam

No, I'd rather not.  That would create massive debugging problems
   if one of those I/O backends actually tried to make calls into the
   kernel API.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>