Skip to content

Document EventSourceLoggerProvider non-caching behavior#124075

Merged
cincuranet merged 4 commits intomainfrom
copilot/fix-memory-leak-eventsource-logger
Feb 11, 2026
Merged

Document EventSourceLoggerProvider non-caching behavior#124075
cincuranet merged 4 commits intomainfrom
copilot/fix-memory-leak-eventsource-logger

Conversation

Copy link
Contributor

Copilot AI commented Feb 6, 2026

Description

EventSourceLoggerProvider.CreateLogger() returns a new EventSourceLogger instance on each call without caching. This differs from ConsoleLoggerProvider which caches by category name. The behavior is intentional (maintains linked list for dynamic EventSource/ETW configuration changes), but was undocumented, leading to confusion when libraries like Serilog call CreateLogger() per log event.

Changes

XML Documentation Updates:

  • EventSourceLoggerProvider class and CreateLogger() method: Document non-caching behavior and caller responsibility
  • EventSourceLogger class: Explain linked-list tracking for ETW dynamic configuration
  • EventSourceLoggerFactoryExtensions.AddEventSourceLogger(): Clarify caching expectations

README.md:

  • Added "Important Notes" section explaining caching behavior
  • Clarified that standard ILoggerFactory handles caching (normal DI usage unaffected)
  • Noted direct ILoggerProvider.CreateLogger() calls require caller-side caching

Impact

Documentation-only change. No behavioral modifications.

Normal usage through ILoggerFactory (dependency injection) is unaffected as it already implements per-category caching. Only direct ILoggerProvider.CreateLogger() consumers need awareness.

Microsoft Reviewers

Note: Canned responses can be used if appropriate.

Original prompt

This section details on the original issue you should resolve

<issue_title>Possible memory leak in EventSource logger?</issue_title>
<issue_description>### Description

I am seeing a huge number of EventSourceLogger instances when I compare memory dumps over time from my application:
image

It seems that EventSourceLoggerProvider blindly creates new EventSourceLogger instances and adds them to the linked list. This is different from for example the console logger, which have instances in a dictionary keyed by the logger name.

What is the exact contract provided by CreateLogger(name)? Is it the provider internally that should guarantee that the same logger is returned for a given name (as the Console logger does), or is it the caller?

Of cause, if it is up to the caller to cache by name, then this is a bug in Serilog.

Reproduction Steps

Create a simple console app with the following references:

<PackageReference Include="Microsoft.Extensions.Hosting" Version="6.0.1" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="6.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.EventSource" Version="6.0.0" />
<PackageReference Include="Serilog.Extensions.Hosting" Version="4.2.0" />

And the following Program.cs:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Serilog;

var host = Host.CreateDefaultBuilder()
    .ConfigureServices(services => services.AddLogging(builder => builder
        .ClearProviders()
        .AddEventSourceLogger()))
    .UseSerilog((context, config) =>
    {
    }, writeToProviders: true)
    .Build();
var logger = host.Services.GetRequiredService<ILogger<Program>>();

while (true)
{
    logger.LogInformation("Hello");
}

The app will continue to allocate EventSourceLogger instances indefinitely.

Expected behavior

The EventSourceProvider should return EventSourceLogger instances keyed by name such that the linked list internally in the provider does not grow indefinitely.

Actual behavior

New EventSourceLogger instances are blindly created for every call to CreateLogger(name), which are internally stored in the linked list.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response</issue_description>

<agent_instructions>Improve docs around EventSourceLogger and explicitly state that instances are not cached and it is expected from client side.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@ Tagging subscribers to this area: @dotnet/area-extensions-logging See info in [area-owners.md](https://github.com/dotnet/runtime/blob/main/docs/area-owners.md) if you want to be subscribed.
Issue Details

Description

I am seeing a huge number of EventSourceLogger instances when I compare memory dumps over time from my application:
image

It seems that EventSourceLoggerProvider blindly creates new EventSourceLogger instances and adds them to the linked list. This is different from for example the console logger, which have instances in a dictionary keyed by the logger name.

What is the exact contract provided by CreateLogger(name)? Is it the provider internally that should guarantee that the same logger is returned for a given name (as the Console logger does), or is it the caller?

Of cause, if it is up to the caller to cache by name, then this is a bug in Serilog.

Reproduction Steps

Create a simple console app with the following references:

<PackageReference Include="Microsoft.Extensions.Hosting" Version="6.0.1" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="6.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.EventSource" Version="6.0.0" />
<PackageReference Include="Serilog.Extensions.Hosting" Version="4.2.0" />

And the following ...


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

@github-actions github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Feb 6, 2026
Copilot AI changed the title [WIP] Fix possible memory leak in EventSource logger Document EventSourceLoggerProvider non-caching behavior Feb 6, 2026
Copilot AI requested a review from cincuranet February 6, 2026 08:55
@github-actions github-actions bot added area-Extensions-Logging and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Feb 6, 2026
@cincuranet cincuranet marked this pull request as ready for review February 10, 2026 12:07
Copilot AI review requested due to automatic review settings February 10, 2026 12:07
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates documentation in Microsoft.Extensions.Logging.EventSource to clarify that EventSourceLoggerProvider.CreateLogger() does not cache EventSourceLogger instances, and that repeated direct calls can create many loggers (surprising some consumers such as Serilog).

Changes:

  • Documented non-caching behavior on EventSourceLoggerProvider and CreateLogger().
  • Added remarks to EventSourceLogger describing instance creation/tracking behavior.
  • Added an “Important Notes” section to the package README describing caching expectations.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File Description
src/libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLoggerProvider.cs Adds XML remarks about non-caching and why created loggers are retained.
src/libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLoggerFactoryExtensions.cs Adds remarks clarifying caching expectations for the provider/extension.
src/libraries/Microsoft.Extensions.Logging.EventSource/src/EventSourceLogger.cs Adds remarks about non-caching and linked-list tracking.
src/libraries/Microsoft.Extensions.Logging.EventSource/README.md Adds “Important Notes” section explaining caching behavior and typical DI usage.

@cincuranet
Copy link
Contributor

/ba-g Failures are unrelated to changes.

@cincuranet cincuranet merged commit bcc15a0 into main Feb 11, 2026
83 of 91 checks passed
@cincuranet cincuranet deleted the copilot/fix-memory-leak-eventsource-logger branch February 11, 2026 12:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Possible memory leak in EventSource logger?

4 participants