Project

General

Profile

Bug #3633

kernel panic due to debugging a user-land software

Added by Denis Kozadaev over 7 years ago. Updated over 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2013-03-17
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

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:

::panicinfo

cpu 0
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

#1

Updated by sham pavman over 7 years ago

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!

#2

Updated by Denis Kozadaev over 7 years ago

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.

#3

Updated by Dan McDonald over 7 years ago

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

#4

Updated by Yuri Pankov over 7 years ago

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).

#5

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()

Also available in: Atom PDF