[Canary] lib: monkey: proceed oversized fired events on windows

[cosmo0920]

This is a Canary PR. DO NOT MERGE THIS.

Currently, monkey core does not have a bound of firing events.
This PR adds a capability for proceeding out-of-bounds sized events on monkey core.

What is wrong. The libevent backend allocates ctx->fired once, at loop creation, with 256 entries for the engine loop, and never grows it. cb_event and _mk_event_inject append to it with no bounds check, so the 257th event that becomes ready in a single event_base_loop pass writes past the heap block. The reporter's stack trace, page-heap fault, and the fired_count of 546 in the 5.0.7 dump all match this. Only Windows is affected in practice, since the epoll and kqueue backends pass queue_size to the kernel and cannot overrun.

The fix, in mk_event_libevent.c:

• Grow the fired array on demand. A new helper, mk_event_fired_push, doubles the array with mk_mem_realloc when it is full, and both append sites go through it. If the realloc fails, the notification is dropped instead of overflowing. That is safe because the events are level triggered and persistent, so a still-ready descriptor fires again on the next pass. Growing inside the callback is safe: I checked every consumer, and all of them re-read ctx->fired through the context pointer rather than caching a pointer into it.
• Deterministic timer teardown. The reporter's secondary claim of a double close and double free does not actually occur, because the timer and the read-side registration used two separate ev_map structs. What was real is that the timer's ev_map, its write socket, and its libevent timer lived on until cb_timeout noticed the peer was closed, and leaked entirely if the event was removed via plain mk_event_del or the loop was destroyed. Now one ev_map owns the socket pair and the timer, _mk_event_del stops the timer, unregisters, and closes both ends in one place, and cb_timeout only signals. _mk_event_del also now unregisters from libevent before closing sockets, since on Windows a closed handle can be reused by another thread immediately.

Regression test in flb_event_loop.c: it creates a loop of size 64, registers 256 pipes that are all readable at once, and drains them. It is backend-neutral, since epoll simply needs more passes.

Verification with the NMake Debug tree in build/:

Run	Result
New test, old backend	crashes with access violation 0xc0000005
New test, fixed backend	passes
Full flb-it-flb_event_loop suite	passes
flb-it-scheduler suite (real timer create/destroy path)	passes

Mitigation for users until a release ships is to keep the number of simultaneously ready events under 256: a finite Retry_Limit on the forward output, storage.max_chunks_up below 256, and storage.total_limit_size to bound the backlog. These reduce the odds but do not remove the bug.

Related to #11905.

This patch is fully included in monkey/monkey#446.

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

• Example configuration file for the change
• Debug log output from testing the change

• Attached Valgrind output that shows no leaks or memory corruption was found

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

• Run local packaging test showing all targets (including any new ones) build.
• Set ok-package-test label to test for all targets (requires maintainer to do).

Documentation

• Documentation required for this feature

Backporting

• Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}