Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Memory leak with the Microsoft Dependency Injection job factory

See original GitHub issue

Describe the bug

Quartz.NET appears to leak memory when running jobs with the Microsoft.Extensions.DependencyInjection job factory.

Version used

3.6.3

To Reproduce

https://github.com/danports/MemoryLeakTest

Expected behavior

Memory usage should remain relatively stable; instead, it increases without bound:

Additional context I’m wondering if Quartz.NET is not properly disposing the service scope created for running jobs - when I review the heap in the debugger, it appears that none of the ApplicationDbContext instances are freed even though some of the TestJob instances are.

Issue Analytics

State:
Created 2 months ago
Comments:6

Top GitHub Comments

2reactions

danportscommented, Jul 28, 2023

Alright, upon further investigation, this is an issue with neither Quartz.NET nor the Sentry .NET SDK - it’s a known problem with the runtime (https://github.com/mono/mono/issues/19665), which apparently gets triggered through the (indirect) interactions between Quartz.NET and Sentry when a Quartz job fails and Sentry logs the exceptions. I guess I got lucky with the previous scheduling engine I was using because it didn’t trigger this issue, which made me suspect Quartz.NET when it was actually the runtime at fault. Sorry for the false alarm!

0reactions

danportscommented, Jul 28, 2023

When I remove Quartz.NET from the repro project (by cutting out the scheduler and executing the TestJob directly), I am unable to reproduce the problem, so I can’t yet rule out an issue with Quartz.NET. Continuing to dig deeper.