Closed FLEx, but it still leeches from your machine?

Before I try and get technical, I want to see if any of y’all who use FLEx, regardless of ~techiness~, run into this: you’re finished working with FLEx for the time being, and you close it (what a lovely feeling). But your computer gets and stays rather angry–the fan keeps going, it’s slow in pulling local files up for whatever you’re doing next, it’s slow to even switch between windows or tabs on a browser. Do you face this? Do you have to restart your computer entirely every time you use FLEx? I’m talking about after having closed FLEx. It’s well established that it’s a heavy program while being used, but I would personally expect that shutting something down would…shut it down. If you’ve noticed this, do you notice any patterns about when it occurs? I’m starting to think it doesn’t happen every time, just very often. I’d like to know about your experiences!
If you’re satisfied with this much of the post and have something to say, feel free to stop here and chime in! Below is just some technical hypothesizing.
I haven’t quite figured out the actual patterns around it but I did bring it up in a Twitter thread here a while ago. See Luke Gessler’s answer for a helpful breadcrumb.
So I think it has to do with FLEx’s use of XPCOM. But I’m not quite satisfied, since Firefox theoretically uses XPCOM too, and it doesn’t stay greedy after being closed. The real issue is that it stays running even after FLEx is gone. When there is no other evidence of FLEx being around, running top shows me that there is a process called MainThread that is consuming massive amounts of memory and processing power (not to mention my battery goes from lasting ~40min to lasting ~10; doesn’t sound like a large step down but that’s 25% of generally what I hope for).
I think one possibility for why it seems to generally happen but not always could be that it occurs when there’s an error that causes the program to crash. Maybe the devs didn’t program it to close out that process when the app hits such an exception. I guess?

Testing this kind of thing for replicability is a pain in the neck, too. I of course want to know if the behavior is the same on Macs with Parallels or a VM or PCs on any given OS (my machine runs Ubuntu 18.04). But I also don’t really want to ask people to break projects, nor am I quite sure about how to (and whether it’s safe to) provide a nonce broken project or give instructions to break a nonce project lest something drastic and lasting occur. Also, I would be curious if it’s really MainThread that is doing the harm? Is that a symptom of some other thing going on, or is it the end of the trail and killing it does enough? MYSTERIES


Huh, interesting. This really does sound like a hard thing to debug.

I wonder if you might try posting an issue on the FLEx Github repo?

So many layers of stuff.:woozy_face:

1 Like

haven’t had this but I have an issue with FLEx that when I send/receive, I can do it once per session. If I try a second time, it does sync, but flex doesn’t restart, it hangs. But if I force close and restart it will often say that an instance of FLEx is already running (even though in theory it as closed). That implies that there is something that doesn’t close properly.


WOW that’s fascinating! I honestly think these might be related to the same underlying issue. Is that with a send/receive on a flash drive? Or LanguageDepot? And is this on a Mac with Parallels (or something else?), a Windows machine, or Linux?


language depot and windows10. It’s been true for the last year or more (so the most recent updates to flex didn’t solve it)

1 Like