[Bug 293382] Dead lock and kernel crash around closefp_impl

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293382

--- Comment #16 from Paul <devgs@ukr.net> ---
Alas, it was optimized out. Probably because its value is in a register?

(kgdb) fr 19
#19 knote_fdclose (td=td@entry=0xfffff80586c4e740, fd=fd@entry=303514) at
/usr/src/sys/kern/kern_event.c:2704
2704                            kn_enter_flux(kn);
(kgdb) p *kq
value has been optimized out
(kgdb) p kq
$4 = <optimized out>

Using a brute force approach, looks like r15 is a correct guess:

(kgdb) i r
rax            0xfffff80586c4e740  -8772357134528
rbx            0x4a19a             303514
rcx            0x121               289
rdx            0xffffffff811ab239  -2128956871
rsi            0x4                 4
rdi            0xdeadc0dedeadc0f6  -2401050962867404554
rbp            0xfffffe0718b5edc0  0xfffffe0718b5edc0
rsp            0xfffffe0718b5ed80  0xfffffe0718b5ed80
r8             0x1                 1
r9             0xffffffff81e1efc8  -2115899448
r10            0x0                 0
r11            0x4                 4
r12            0xfffff801090cad18  -8791646229224
r13            0xfffff83937739f00  -8550349562112
r14            0x4a19a             303514
r15            0xfffff801090cad00  -8791646229248
rip            0xffffffff80b25c9e  0xffffffff80b25c9e <knote_fdclose+302>
eflags         0x10297             [ CF PF AF SF IF RF ]
cs             0x20                32
ss             0x28                40
ds             <unavailable>
es             <unavailable>
fs             <unavailable>
gs             <unavailable>
fs_base        <unavailable>
gs_base        <unavailable>
(kgdb) p *((struct kqueue*)$r15)
$14 = {
  kq_lock = {
    lock_object = {
      lo_name = 0xffffffff812bbf6c "kqueue",
      lo_flags = 21168128,
      lo_data = 0,
      lo_witness = 0xfffff8804bd8da80
    },
    mtx_lock = 18446735301352417088
  },
  kq_refcnt = 0,
  kq_list = {
    tqe_next = 0xfffff80155923a00,
    tqe_prev = 0xfffff80150f62d28
  },
  kq_head = {
    tqh_first = 0x0,
    tqh_last = 0xfffff801090cad38
  },
  kq_count = 0,
  kq_sel = {
    si_tdlist = {
      tqh_first = 0x0,
      tqh_last = 0x0
    },
    si_note = {
      kl_list = {
        slh_first = 0x0
      },
      kl_lock = 0xffffffff80b254e0 <knlist_mtx_lock>,
      kl_unlock = 0xffffffff80b25500 <knlist_mtx_unlock>,
      kl_assert_lock = 0xffffffff80b25520 <knlist_mtx_assert_lock>,
      kl_lockarg = 0xfffff801090cad00,
      kl_autodestroy = 0
    },
    si_mtx = 0x0
  },
  kq_sigio = 0x0,
  kq_fdp = 0xfffffe07143ca920,
  kq_state = 0,
  kq_knlistsize = 700672,
  kq_knlist = 0xfffffe09b7213000,
  kq_knhashmask = 0,
  kq_knhash = 0x0,
  kq_task = {
    ta_link = {
      stqe_next = 0x0
    },
    ta_pending = 0,
    ta_priority = 0 '\000',
    ta_flags = 0 '\000',
    ta_func = 0xffffffff80b26060 <kqueue_task>,
    ta_context = 0xfffff801090cad00
  },
  kq_cred = 0xfffff804a3517700
}


Yeah, 303514 is definitely a valid descriptor value. We do handle hundreds of
thousands of websocket connections normally. And yes, our limits are adjusted
to several millions, just in case...

We will consider using HEAD for a test run, without updating the world. We will
stay in touch and report back as soon as there is something to report.

In any case, if you need more info, we will be glad to provide it.

-- 
You are receiving this mail because:
You are the assignee for the bug.