Why Must I FORCE QUIT DAZ Studio to Shut It Off?
Fauvist
Posts: 2,114
Every time I want to close DAZ Studio I quit the application, and I get a message about wanting to save the file or not. I either click "yes" or "no" - then it appears to close because it disappears off my PC desktop. But the DAZ Studio application icon is still lighted up indicating that the application is still open. I click on the icon and I get the option of FORCE QUITing it - meaning it's still on - only, I can't open it up again until I FORCE QUIT it. If I Force Quit it - it can damage the last file that was open. How do I stop this from happening. It started doing this about 2 weeks ago.
Thanks!
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
If you wait long enough the errant thread that is still rendering will eventually stop. At least on my PC it does although sometimes it seems to take 30 minutes. The exception is though when I render for Speed at product that uses too much memory for my CPU render PC (16GB RAM), eg HowieFarkes Harpwood Nature Trail scene. I click & I click and the render keeps running but nother gets draw to canvas. I kill DAZ Studio & restart the render optimized for Memory instead of Speed. Try it. It is slower though... :-(
What is an errant thread that is rendering? I don't use iray, I use 3Delight. There is nothing rendering when I try to quit the program. When I save the scene, it creates a new file each time that shows up on my destop. I can see from the icon that it has finished.
On my PC how long it takes the underlying DAZStudio process to quit depends on what I was doing. If I had used it only for a small scene, like one character, it will quit in a few seconds. If I had a large scene with 5-10 DAZ characters loaded, it usually takes a couple of minutes to quit. When I have been rendering large scenes, I have seen it take 10-15 minutes for the underlying DAZ process to quit. In those cases it was clear that the problem was page faulting. The DAZ process had used so much memory at some point that parts of the data/application had been paged out. It seemed to need to page much of that data back into memory before quiting.
I generally don't like to force quit the DAZStudio process. When I was using 3Delight, one of the things this DAZStudio process was doing after the window closed was to clean up the files that had been created in the temp area. Starting another process using the same temp area seemed to be a frequent cause of file corruption in the 3Delight temp area. Killing the process before it had cleaned up the temp area could also cause corruption. I have never seen this issue with Iray, but I am still careful about letting the process quit.
Okay, thanks and also thanks nonesuch00 - I'll leave it finish on it's own!
Oh, my DAZ Studio leaves a 'errant thread' when memory is too much memory or the forked thread is busy (rendering but needed only be rendering) and not listening to it's parent (DAZ Studio) to stop. I know it's rendering because that is the only time my laptop gets really noisy with fans.
Also having this slow turn off problem. I'm on the OSX version.
I posted about this same issue some weeks ago. Never got a way to fix it.
Greetings,
So...it's probably not rendering. Your laptop will get noisy with fans when your CPU is being pressed hard for a bit of time. That does happen during rendering, but it also happens when it's walking a complex set of memory allocations, trying to free them all (for example).
This is actually a very old category of bug for DAZ 3D. For a period of time, every beta would do this. If you go back in the beta histories, you'll see stuff about 'Fixed DS crash on close'. Those crashes didn't usually happen immediately; the process would stay in existence for a while, and then maybe 4-5 minutes later would finally give up the ghost and crash. Often it's a memory corruption; e.g. if a cycle gets inserted in the memory allocations, so when it's walking the tree to free memory, it gets dropped into a leaf node again, and walks the same memory back up, re-freeing it. (Just an example, probably not what's happening here. But the idea of getting into an infinite loop that only ends when something crashes is the likely outcome.)
I remember it happening back in 4.6 betas and probably earlier. They usually either (1) fix it for the release, or (2) it's failing because of debug code that's in the beta. In this case, I'm also seeing the problem, although typically on Windows, and it actually messed me up. I did a DAZ Studio install when I thought the app wasn't running, but it was (several hours later) still running, stuck. When you install DS with it running, it corrupts the install pretty badly...
Anyway, if you've saved your scene, and the save has completed, and the UI has been closed down, then you can generally kill the app with impunity.
-- Morgan
Thanks. Given it did the memory allocs as part of the render process...I consider that part of the rendering but yes anything that drives the CPU hard enough to get hot will cause the fans to kick on. I only get it for example with memory intensive scene when I try to render them like Harpwood Trails from HowieFarkes. I change from Speed to Memory optimization and it goes away although it's an even slower CPU render.
Yes, I'm also on Mac OSX.
Daz Studio exits very quickly for me. And crashes as it does so. I just kill it (Windows gives me a nice popup to do that so I don't have to run my preferred task manager). It's very annoying and just started with the latest update.
So one way or the other, trying to exit is just asking for trouble.
I'm a Mac OS user. I find that if you log in to DAZ Studio, it has a lot of trouble or fails to log out. When you log out or quit, DS often hangs indefinitely. One answer is not to log in. Oh, I occasionally log in to pick up metadata that might not get loaded through DIM, but for the most part I don't log in. Another answer is force quit.
I also sometimes cannot cancel a render. One answer is force quit. Another is to allow the render to complete, depending on how long to finish the render. As this problem means I might have to cancel any render, this has got me in the habit of saving before every render.
@SethM "Daz Studio exits very quickly for me. And crashes as it does so. I just kill it (Windows gives me a nice popup to do that so I don't have to run my preferred task manager). It's very annoying and just started with the latest update.
So one way or the other, trying to exit is just asking for trouble."
Thats not my experience with Studio. It shuts down normally and stops any process within a few seconds.
Exiting Studio (on Mac) always takes a while. I watch the system monitor while Studio carefully frees memory before exiting. I'm not at all sure that it is necessary for an application to do this.
What do you mean "log in"? I just start the application. I don't log in to anything. Or does DAZ Studio automatically log into something?
No mater what I do, I've noticed I need to force quit DAZ Studio, even if I just start it and close it. I don't use it that often.
I think it has to do with my System Drive, which I think is going to give up the ghost here soon. I have a replacement, I just need to put it in the mini. That is my reason for writing it up as a bug.
I think he means logging into DAZ Connect, which isn't needed unless you've installed content that way.
I created a little script, that at least improves the closing speed.
One simple thing you can do which does help (or at least it helps me): Don't exit Studio without first using the New icon. That is, always exit Daz with absolutely nothing loaded in scene.
Studio has nearly nonexistent "garbage collection" (freeing of used memory when it is no longer needed). Say you're doing a lot of work in one set. You load a figure into the scene, do some renders with that, delete the figure, load a different figure in, do some work with that one, delete it ... THEY ARE NOT REALLY GONE. The space that could now be used (from the deleted figures) was not freed up. So, if you work for several hours your scene gets bigger and bigger in memory, and Studio does garbage collection in memory in ONLY four situations, as far as I can tell:
1. When you exit
2. When you press New Scene
3. When you load a scene and there is some deleted-but-not-really stuff lying around to clean out
4. When you run the old Purge Memory script somewhere in the dev resources--but this script has not been updated in years and locks up two times out of three so you probably don't want to try it.
Anyway, the point is, if YOU clear out memory manually by pressing New Scene before you leave, there's less for the invisible cleanup-on-exit task to do and thus it doesn't linger around nearly as long.
Also, I know it sometimes can't be avoided, but if you force-quit Studio, it does not shut down the Postgres database processes (usually five or six of them) and this may cause issues when you restart Studio again unless you also find those and shut them down by hand. Richard Haseltine has been warning people for ages that force-quitting Studio has the possibility of corrupting DB (it's low; you have to catch it while they're in the middle of actually doing a DB write, but it could happen).
EDITED in view of experimental results downthread! Merge cleans out just as well as Open does, if it has reason to.
Nw clears the undo stack, and I would suspect that deleting items one by one pushes some of the deletions off the stack and so clears that data (the number of steps on the stack varies by how much data they contain) - less data to clear up means a faster shut down (and yes, it does collect garbage - otherwise these clean-ups would not happen).
I have found that I don't get the same cleanout by manually deleting everything in the scene that I do by pressing New. That is, a scene which is empty because I've deleted everything in it by hand is still eating more memory than after pressing New. Ergo, New is doing some cleanup that manual deletions do not do. I've actually gone to the trouble of monitoring Studio's memory consumption for comparison purposes because I've been curious about this.
I didn't mean to imply that Studio does no garbage collection, Richard, but it sure looks like you generally have to do something to CUE it to do so, and I feel like hand-deletion of scene elements does NOT.
Just for fun and because I hadn't done one of these in a while (and not to start an argument with Richard, who is a gentleman and a scholar):
1. Clean startup of Studio. No action, did not load anything, just started it, waited for it to fully launch, and checked Task Manager.
319.4 MB used in memory
2. Loaded a rather large .DUF and gave it time to let its stomach settle (once it's loaded and all the refitting and such subsides, you still need to give it a second because it does free some memory that it used for the fit-to processing and so forth).
8892.3 MB used in memory
3. Manually deleted every single thing in the scene including the Tonemapping and Environment nodes. Let its stomach settle, again, and then checked the numbers.
8816.1 MB used in memory
Oooh! So it didn't really free much of anything. Now, the question is, is it keeping that memory allocated but is prepared to reuse it efficiently, or is that memory unusable junk space now? The test is to MERGE in (not use a clean Open, which we know does a New first) a scene and see what happens. If that's an available pool for Studio to use, then if we, say, load the same scene again, it shouldn't rise by much; it should go back to something close to that 8892.3. Reusing the space. But if that space is dead, we could suddenly see an allocation that is double this.
4. Merged in the same scene again. AND A FASCINATING THING HAPPENED. Well, fascinating to me.
I got a "Deleting objects" progress bar during the merge load. This is an indicator of memory cleanout! I think I must never before have merged something into a scene where there was already deleted stuff lying around taking up space. So apparently a Merge does do a cleanup first the same way an Open does--if it has reason to do so. Good to know!
Under the circumstances, I wouldn't expect it would take up much more space than the original scene load, since it did clean out the pool. It's a little leaky, but not much:
8999.0 MB used in memory
5. And now we'll press New to see what it gets back down to:
522.4 MB used in memory
Again, a little bit leaky ... it'd be lovely to get it down to closer to the 319.4 we began with. But most software is at least this leaky or worse, and Windows memory management (which is, was, always has been horrible) doesn't make it easier.
ANYWAY, the point is, if you exited Daz after deleting all the items in that scene by hand, you'd have to wait for it to try to free up an 8816 MB allocation, silently, in the background, before it really exited; if you pressed New and let that do its thing before you exited, it would have much less invisible work to do before it could say bye-bye for real.
Collecting the garbage is the sensible thing to do when deleting an object and continuing to use the app. However it makes no sense whatsoever when an app is about to close, as who cares about the freed up data? It is obvious that DS deletes all objects as it closes, but I have yet to here a convincing reason why it needs to do this. It should just unreference the root object then quietly (and quickly) die. I understand that DS does save a few screen layout arguments as it is closed, but of the ones I am aware of, none are affected by what was in the scene, and therefore can not be saved until after the scene has been cleared.
Yeah, that'd be one of my two questions I don't expect we'll ever get an answer on. In Windows (I don't vouch for Macs) they definitely had the option to say "process ending, here's all the space we were using back, bye" and have done. Instead they choose to use their own internal deallocation, running silently while that finishes.
The other question is, why does Studio's internal deallocation take so LONG? Clearing-out-memory times of several minutes aren't uncommon (and, as I noted in the other thread, there are a couple of things you can do to really mess with Studio's head and then you get ridiculous results--I had a scene that took over forty minutes to clean out!)
Richard hinted at the reason when he talks about the undo stack. When a figure is deleted, then the figure's shape, pose, materials, plus all wearables must be saved to the undo stack so that if someone clicks undo, then the figure returns exactly as before. This understandably takes time. Now of course if we are closing the app, why do we care about the ability to undo?
Did you select all and then delete? The suggestion earlier, which I haven't tested but about which i was hypothesising, was that selecting and deleting items one-by-one would clear soem of them from memory because the undo stack couldn't (depending on number and size) hold all of them. Selecting all and deleting wouldn't do that as it would be a single operation, so it would sit on top of the undo stack regardless of size (up to the point when it was simply too big to be undoable, if that is possible).
Norton Utilities has a tool to clear (defragment) RAM and I use it like every 10 minutes when I'm using DS. RAM gets used up or "fragmented" super fast using DS in just a few minutes of using it and Norton Utilities really helps crashes. It might solve the close down issue too as it seems to solve a lot of problems for me.
I did a couple of tests. In one of them I deleted the items one by one and in the other I just selected them all and then deleted them. I didn't write down the numbers for the first test, but that's because it didn't seem to make a significant difference either way.
OK, thank you. Others have reproted that it does make a difference, it may depend on the exact nature of the scene if so.