Skip to content

CI run for upstream PR bUnit-dev/bUnit#1956 - #1

Closed
xaviergxf wants to merge 1 commit into
mainfrom
fix/waitfor-timer-leak
Closed

xaviergxf wants to merge 1 commit into
mainfrom
fix/waitfor-timer-leak

Conversation

@xaviergxf

Copy link
Copy Markdown
Owner

Opened on the fork only to run the ci workflow on the branch behind bUnit-dev#1956, since first-time contributor runs on the upstream repo wait for a maintainer's approval. Not for merging here.

…started

When a WaitFor* check passes synchronously, the helper disposes itself from
inside the constructor, while the timer field is still null. The constructor
then looks at WaitTask.IsCompleted to decide whether to start the timer, but
WaitTask is a WhenAny(...).Unwrap() that completes on the thread pool, so it
usually still reads as not completed at that point and the timer is started
anyway. The later Dispose() from the using block returns early because the
helper is already disposed, and nothing ever stops the timer.

The timer's state is the helper, so until the timeout elapses it roots the
helper, the rendered component, the renderer and everything the renderer
holds. With bUnit's default timeout of one second that goes unnoticed. With a
long DefaultWaitTimeout, a test suite keeps every page it rendered in memory
for its whole run.

The constructor now also checks isDisposed before starting the timer, and
disposes the timer right after creating it if the check disposed the helper in
between.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@xaviergxf

Copy link
Copy Markdown
Owner Author

The ci workflow is now registered on the fork and was started directly on the branch, so this PR is not needed.

@xaviergxf xaviergxf closed this Oct 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant