Bug #3633
kernel panic due to debugging a user-land software
0%
Description
I wrote a small program to catch packets from a network interface.
http://silversoft.net/~denis/pkt_catcher.c (compiled by gcc)
When I debugged it in gdb step by step, the kernel was panic.
some info from mdb:
cpu 0::panicinfo
thread ffffff0005cc5c40
message assertion failed: msg_size == msgdsize(mp), file: ../../common/fs/sockfs/sockcommon_sops.c, line: 1261
...
the dump is available here:
http://silversoft.net/~denis/vmdump.7
History
Updated by sham pavman over 7 years ago
Updated by I modified your test program to run for 20 mins and in that time i did not see any panics.
Is this issue your facing coming only when you gdb through the program?
I'm running on OI_151a7 and i've not seen this issue!
Updated by Denis Kozadaev over 7 years ago
Updated by I got the panic when the program was stopped in a debugger,
probably, it was overflow of a kernel queue.
Of course, it does not panic until the program stopped.
btw, OI version was the same.
Updated by Dan McDonald over 7 years ago
Updated by Sham --> an ASSERT only trips on a DEBUG kernel. Build your own DEBUG kernel and onu to it.
Denis --> I'm assuming you compiled your kernel debug, as you wouldn't trip an ASSERT any other way.
so_queue_msg_impl() gets a size passed to it, but it doesn't match the msgdsize(mp) of the mblk chain passed into it. Question is, how? Single-stepping SHOULDN'T be a factor in causing it, but you never know....
Updated by Yuri Pankov over 7 years ago
Updated by Dan McDonald wrote:
Sham --> an ASSERT only trips on a DEBUG kernel. Build your own DEBUG kernel and onu to it.
Denis --> I'm assuming you compiled your kernel debug, as you wouldn't trip an ASSERT any other way.
so_queue_msg_impl() gets a size passed to it, but it doesn't match the msgdsize(mp) of the mblk chain passed into it. Question is, how? Single-stepping SHOULDN'T be a factor in causing it, but you never know....
Indeed, it isn't - I've reproduced the issue leaving the pkt_catcher running overnight, the system is pretty much idle VM (used for builds only).
Updated by Yuri Pankov over 7 years ago
> ::panicinfo
cpu 4
thread ffffff000fec5c40
message assertion failed: msg_size == msgdsize(mp), file: ../../common/fs/sockfs/sockcommon_sops.c, line: 1261
rdi fffffffffbfa2c30
rsi ffffff000fec5750
rdx fffffffff7bedd98
rcx 4ed
r8 ffffff000fec56a0
r9 ffffff000fec5790
rax 0
rbx 4ed
rbp ffffff000fec5780
r10 fffffffffc083dd8
r11 fffffd8000000000
r12 fffffffff7bedd98
r13 fffffffff7beda98
r14 ffffff000fec58cc
r15 0
fsbase 0
gsbase ffffff02ede41580
ds 4b
es 4b
fs 0
gs 1c3
trapno 0
err 0
rip fffffffffb8781c0
cs 30
rflags 246
rsp ffffff000fec5698
ss 38
gdt_hi 0
gdt_lo 500001ef
idt_hi 0
idt_lo 70000fff
ldt 0
task 70
cr0 8005003b
cr2 8140a34
cr3 4000000
cr4 6b8
> $C
ffffff000fec5780 vpanic()
ffffff000fec57c0 assfail+0x73(fffffffff7beda98, fffffffff7bedd98, 4ed)
ffffff000fec5860 so_queue_msg_impl+0x553(ffffff02f6ae2040, ffffff02ea057e60, 14, 0, ffffff000fec58cc, 0, 0)
ffffff000fec58b0 so_queue_msg+0x2f(ffffff02f6ae2040, ffffff02ea057e60, 14, 0, ffffff000fec58cc, 0)
ffffff000fec5980 pfp_packet+0x322(ffffff14b78b1a38, 0, ffffff02f3a02d60, 0)
ffffff000fec59d0 mac_promisc_dispatch_one+0x94(ffffff0379238f70, ffffff02f367f760, 0)
ffffff000fec5a40 mac_promisc_dispatch+0x110(ffffff02f138fa80, ffffff02f367f760, 0)
ffffff000fec5a90 mac_rx_common+0x3e(ffffff02f138fa80, ffffff02f129fe60, ffffff02f367f760)
ffffff000fec5ae0 mac_rx+0xac(ffffff02f138fa80, ffffff02f129fe60, ffffff02f367f760)
ffffff000fec5b20 mac_rx_ring+0x4c(ffffff02f138fa80, ffffff02f129fe60, ffffff02f367f760, 0)
ffffff000fec5b80 e1000g_intr+0x172(ffffff02f12f4000)
ffffff000fec5be0 av_dispatch_autovect+0x8f(12)
ffffff000fec5c20 dispatch_hardint+0x33(12, 0)
ffffff000fe95a70 switch_sp_and_call+0x13()
ffffff000fe95ad0 do_interrupt+0xfb(ffffff000fe95ae0, ffffff02ede58a88)
ffffff000fe95ae0 _interrupt+0x1e9()
ffffff000fe95bd0 mach_cpu_idle+6()
ffffff000fe95c00 cpu_idle+0xaf()
ffffff000fe95c20 idle+0x114()
ffffff000fe95c30 thread_start+8()