I suspect this has to do with the new module discovery code. Could you maybe produce a log with strace so that we can see what it tries to crawl and if ends up in a loop?

I've encountered this too. I couldn't get strace to output to a file without hanging, but here's the last bit of the output before I stopped it after 5 minutes: https://gist.github.com/domdfcoding/0aea640a1ae3fefa0d046bfdd9ea70c2

The output was pretty much the same before this.

In those 5 minutes the memory usage the memory usage rose from 20MB to over 100MB. When I first noticed this it had been running for about an hour and ended up using 13GB of memory.

Thanks. Looks like we have to try to deal with mount points or at least blacklist some paths - including wine specific paths, /sys, /proc.

Sorry for late response. Same strace output with @domdfcoding

stat("./PlayOnLinux's virtual drives/HOI/drive_c/users/ozgur/Desktop/workspaces/AndroidStudio/AndroidTVappTutorial/app/build/generated/not_namespaced_r_class_sources/debug/r/androidx/drawerlayout", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

Still appears to be an issue for me, I use a variety of tools including Proton and Lutris.

Steam seemed to have an infinite depth wine prefix scanning problem in ValveSoftware/steam-for-linux#7372 (comment) which may be related.

I think there should be some upper hard limit at which point no more modules are discovered, say if more than 500MB of memory is consumed then the scanning should be disabled since something clearly went wrong.

Edit: Nevermind, apt package (outdated) was shadowing user-installed v0.21, fixed once I uninstalled the (outdated) system bpython.