Potential memory leak after upgrading to v2.0.0

[ymyzk]

Hello! First of all, thanks for maintaining the library.

I found a memory leak after upgrading wrapt from 1.17.3 to 2.0.0. As we could fix the memory leak by downgrading wrapt to v1.17.3, without touching anything else, we suspect a change in wrapt 2.0.0 might have caused this. I don't have a minimum reproducible case yet, but let me report the issue here first in case other people have more ideas.

• CPython 3.12.12
• Ubuntu 22.04
• Linux 6.12.40 amd64
• We're not using wrapt directly, but using it as a dependency of ddtrace.

[GrahamDumpleton]

What are you using wrapt for? Just function decorators, or are you doing strange stuff with ObjectProxy class?

[ymyzk]

I'm using wrapt as a transitive dependency of ddtrace. Unfortunately, I'm not very familiar with how ddtrace uses wrapt internally. Taking a look at ddtrace's code base, they're using the ObjectProxy class as well: https://github.com/search?q=repo%3ADataDog%2Fdd-trace-py+wrapt+language%3APython&type=code&l=Python

[ymyzk]

It seems that a few issues (not necessarily a memory leak) were reported in ddtrace's repository after the wrapt v2 upgrade.

DataDog/dd-trace-py#14992
DataDog/dd-trace-py#14993

They also pinned ddtrace to use wrapt v1 so far: DataDog/dd-trace-py#14955

Considering these, this might not be an issue with wrapt itself; rather, it's an issue with the wrapt user side.

[GrahamDumpleton]

Unfortunately they don't seem yet to be saying in any of those issues that I can see what they see as the breaking change in wrapt 2.x that is causing the issue for them.

Theoretically the only problem I can think of is that FunctionWrapper no longer defines __iter__() proxy function.

They may have been using FunctionWrapper on a callable object which just so happened to also need __iter__() to be proxied. The better approach would have been to use a custom ObjectProxy derived class if they needed special magic to wrap an object which had both callable and iterable properties.

[GrahamDumpleton]

Okay, think I understand what problem they are likely having. They check whether an object is already wrapped and if it isn't then wrap it. Because of changes in wrapt, their check to see if an object is wrapped is likely not working and so they keep perpetually wrapping the object. This would cause memory growth, as well as ultimately call recursion limit problems.

For checking if wrapped, to be compatible with wrapt 1.x and 2.x, would need something like:

import wrapt

OBJECT_PROXY_BASE = wrapt.ObjectProxy

if hasattr(wrapt, "BaseObjectProxy"):
  OBJECT_PROXY_BASE = wrapt.BaseObjectProxy

def is_wrapped(obj):
    return isinstance(obj,  OBJECT_PROXY_BASE)

[brettlangdon]

@GrahamDumpleton here from dd-trace-py, yeah we have a few places where we are checking if something is wrapped via isinstance(obj, wrapt.ObjectProxy)

We know how to get 2.x support (as you stated), but we have a lot of older versions pinned as wrapt>=1.

We have one integration that does patching at runtime (only way we can access the thing to be patched), so we keep re-wrapping the same function over and over until we hit recursion issues.

Not sure there is much we can do from the wrapt side since the base class was moved to BaseObjectProxy.

[GrahamDumpleton]

An isinstance() check alone is strictly speaking not actually a reliable test here if testing whether you need to dynamically add a wrapper and there is a possibility it has already been applied. I learnt this back when I was at New Relic and needing to do the same for some reason. I have no idea whether New Relic agent was rewritten to extent that still using same trick I originally added, but I will write a blog post about the problem and what one can do. Will also see if I can draft up some guidelines on issue to add to the docs for wrapt.

[GrahamDumpleton]

Blog post on topic of detecting if an object proxy has already been applied.

• https://grahamdumpleton.me/posts/2025/10/detecting-object-wrappers/

[ymyzk]

I'm closing this ticket as this issue turned out to be not an issue within wrapt and the blog post for wrapt users was published. Thank you all for the prompt responses and actions.