Potential leak of `AutofacServiceProvider`

Hi! This might be a bit of a vague question, so apologies in advance if I’m completely off-track.

I’ve been working on leak detection via Autofac.Analysis, and discovered that when ASP.NET Core 2.1 registers the service provider, it doesn’t appear to mark it as a singleton. At runtime the AutofacServiceProvider instance that’s returned is disposable, so AFAIK it’ll end up in the Disposer’s stack (there may still be only one instance, but entries in the stack will grow).

It doesn’t look like there’s any common path in ASP.NET Core that triggers the leak - but it could be a bit of a footgun. Curious whether there’s anything I’m missing here…? Using 4.9 and the latest version of this package. Thanks!

[tillig]

Yeah, I’m not sure. I really tried reverse engineering how the framework wants to get a reference to the provider vs. what you would expect to do in a per-request/per-scope service location thing and… the hosting mechanism over there now is so complex I just got lost. (Though, admittedly, some of the stuff they do with different DI behaviors, like ILEmit vs. dynamic, etc. is sort of interesting.)

I do know that the framework thinks it’s responsible for disposing the root provider… but the consumers of IServiceProvider assume that the provider will be disposed for them, whether it’s at the root level or in a request.

ExternallyOwned may be the way to get around it. Just stop Autofac from tracking it and let other systems - the framework, the user, the service scope - handle the disposal manually. That would at least be reasonably consistent with how lifetime scopes work - you create it, we assume you dispose it. No tracking, no automatic disposal.

[nblumhardt]

👍 the IServiceProvider/ILifetimeScope analogy is pretty good (just very strange that the framework would then expect unique instances, but 🤷‍♂️ ).