-
Notifications
You must be signed in to change notification settings - Fork 27.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
potential listener LEAK detected: at FileMatch.registerListeners #64120
Comments
Also when replacing I see this one:
|
Not sure if the leak warning needs to be adjusted for this case or search should somehow install global listener for all results instead of one per result. |
The first one, if it's an issue we can register the listener globally or once per folder instead of once per file. The second I think is expected because we have to open all the files to perform the replace. cc @sandy081 Maybe we need a way to disable the warning for certain calls. |
That's because it captures a stack trace. Not sure how often events have been registered to get to 33ms. Please file a new issue when you see this often, we can then disable the warning for stable builds |
This was for a typical text search. But what do you think I should be doing here, ignore the warning for now, move the listener to be registered less often, or come up with a way to disable it for this particular instance? |
You can already do that - each emitter can be configured individually using the |
I mean instance of the listener, but yeah moving the listener is better, I will do that in debt week. |
Actually the warning is not a good look, I'll do it in November... |
@roblourens there are still many more warnings printed when doing a search+replace over > 100 files because we easily create more than 100 text models for the text edit and tons of listeners are being created temporarily. Honestly I do not even know how to fix that other than maybe disposing the models in chunks of a 100 while doing the replace operation (/cc @sandy081 @jrieken) |
Its also the same when we do rename that touches hundreds of files. No idea how to fix such. |
Steps to Reproduce:
/cc @jrieken
The text was updated successfully, but these errors were encountered: