Scrivener process continues running after apparently successful Quit

I added the Scrivener 3 process to my Discord game-watch list and caught it showing that I was in Scrivener long after I closed the application. No dock icon is present, no running indicator, but sure enough, the process is in my Activity Monitor.

It’s holding steady at 0% CPU usage, going back and forth between 5 and 6 threads active.

I believe it’s fixed by simply relaunching the application and closing it, but I think it’d be interesting to discover what’s going on. I hadn’t experienced this before with Scrivener 2 (or with any other software that have Discord watch—Discord isn’t really doing anything to the process other than observing that it’s listed by the system).

Is there any kind of profiling I can take that would be useful in determining what the zombie process is doing?

Thanks!

Mmmm, curiously it shut itself down after a long while, sometime in the hour after I made my post (and it had been going for probably 30 minute by then). I’ll watch for when it happens again, if profiling it or supplying some kind of log would be helpful.

If it has 0% CPU usage, I would guess that it’s just sitting in your system’s memory because nothing else has (yet) made use of the space.

Katherine

That would strike me as very odd if true. I’m unaware of any such behavior in macOS.

The phantom thread! Or 5 to 6 threads, in this case.

There’s nothing in Scrivener itself that would cause this, because Scrivener uses the standard macOS frameworks and Apple’s own app infrastructure. So I can only imagine that it is a macOS issue. I can’t reproduce it myself, but once you choose “Quit” from an app menu, the app receives a “Terminate” message. The Apple frameworks then release the entire app from memory, and there is nothing the app itself can do to stay in memory beyond that point. Even a bug causing a memory leak shouldn’t be able to cause this, because macOS releases all memory used by the app on quit. Note that I’m not saying categorically that it isn’t Scrivener’s fault, just that there is nothing I can think of that could cause this on Scrivener’s behalf based on how the frameworks work, and unfortunately I’m unable to test it seeing as I cannot reproduce the issue.

All the best,
Keith

I guess I’m more interested in my original question, which concerned what I can do to investigate once it’s happening. I’ll play with whatever profiling I can whenever it happens next time.

There is no profiling I know of that would give extra info about this. You could try calling up Force Quit to see if Scrivener is still listed there.

It might be down to this introduced way back in Lion:

arstechnica.com/gadgets/2011/07 … -x-10-7/8/

Or the zombie app state that was introduced at the end of last year:

eclecticlight.co/2017/11/06/did … t-napping/

(Scrivener supports automatic termination as described in that article.)

Either way, these are macOS behaviours.

All the best,
Keith

I see. App Nap while “hidden” from the switcher is a far more satisfying answer, which I didn’t realize was something App Nap could do. Thanks.