Bug #1844
closedgdb detach from vkernel causes vkernel to die with SIGILL
0%
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>
Updated by dillon about 14 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
Updated by dillon about 14 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
<dillon@backplane.com>
Updated by sjg about 14 years ago
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 globaldataAh, 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
Updated by dillon about 14 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
<dillon@backplane.com>
Updated by tuxillo over 11 years 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