https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293382
--- Comment #16 from Paul <[email protected]> --- 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.
