Bug #1844

gdb detach from vkernel causes vkernel to die with SIGILL

Added by vsrinivas about 4 years ago. Updated over 1 year ago.

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

0%

Category:-
Target version:-

Description

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.

0x08266e51 <kern_trap+0>: push %ebp
0x08266e52 <kern_trap+1>: mov %esp,%ebp
0x08266e54 <kern_trap+3>: push %edi
0x08266e55 <kern_trap+4>: push %esi
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
0x08266e6a <kern_trap+25>: mov %eax,-0x18(%ebp)
0x08266e6d <kern_trap+28>: mov 0x110(%esi),%edx
0x08266e73 <kern_trap+34>: mov %edx,-0x14(%ebp)
0x08266e76 <kern_trap+37>: mov 0x48(%esi),%eax
0x08266e79 <kern_trap+40>: mov %eax,-0x20(%ebp)
0x08266e7c <kern_trap+43>: mov 0x4c(%esi),%edx
0x08266e7f <kern_trap+46>: mov %edx,-0x1c(%ebp)
0x08266e82 <kern_trap+49>: cmpl $0xc,0x34(%edi)
0x08266e86 <kern_trap+53>: je 0x8266e91 <kern_trap+64>

History

#1 Updated by dillon about 4 years ago

: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

#2 Updated by dillon about 4 years ago

: 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
<>

#3 Updated by sjg about 4 years ago

On Sat, Sep 18, 2010 at 2:10 PM, Matthew Dillon
<> 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
>                                        <>
>

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

#4 Updated by dillon about 4 years ago

: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
<>

#5 Updated by tuxillo over 1 year ago

  • Status changed from New to Closed
  • Assignee deleted (0)

Hi Venk,

I'm fairly confident this is not happening anymore.
Closing this ticket.

Cheers,
Antonio Huete

Also available in: Atom PDF