Jump to content
  • Advertisement
Sign in to follow this  
Hawkblood

Game takes a long time to shut down

This topic is 542 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm using VS2015 C++. My program is quite large. I can compile it, run it, and exit. The problem is when I change something quickly and try to compile it just after exiting, it will tell me that it can't write to the executable. It seems to me that the program is taking longer to unload than it should..... Why?

 

I am handling my memory correctly (I'm sure), but why would it take that long to completely exit?

 

It's only a problem if I make a quick change and compile-- like I needed a negative number, but originally put in a positive by mistake.

Share this post


Link to post
Share on other sites
Advertisement

without seeing your code it's impossible to say, but if you are doing memory management correct and allocate alot(and i do mean, ALOT) of small things at startup, you have to pay a similar cost when deallocating those things when shutting down.  you also have to free resources from the gpu which can take time equally as well, and any other subsystems you use have to be freed.  you might also be waiting on other threads to finish up freeing their memory as well.

 

but this is all speculations as we have no idea what your code base looks like, and what could be happening when you are quiting your game, so what you can do is profile your code and see what is taking a long time to finish up and actually close the program.

Share this post


Link to post
Share on other sites

Define "quite large".  Does it use 10GB of memory?  Does it make tens of thousands of small allocations?  Do you use your own custom memory management?  How large is your code base?  Without knowing things these we cannot even begin to help you.

Share this post


Link to post
Share on other sites

My program is quite large. I can compile it, run it, and exit. The problem is when I change something quickly and try to compile it just after exiting


Are you running under the debugger? Stopping/restarting apps under the debugger force-kills the process so it's impossible to keep running afterward.

If not, run under a debug and Break shortly after quitting and see what it's doing. Or use another form of telemetry (even just logging).

Have you used a tool like Process Explorer to verify that it's running? Or to see what is holding onto the .exe if not the process?

Share this post


Link to post
Share on other sites

Let me be more specific in the sequence of events:

(I run this in "release")

I make changes to my code and compile.

I run the program to see if the changes did what I expected (sometimes it's not what I expected).

I exit the program and it dumps out to the compiler normally.

I make more changes.

I go to compile and that's when it tells me it can't write to the .exe

After a while (less than a minute), I can try to compile again and it works normally.

 

I suppose it's possible that I am not deallocating memory, but I use "vector <>" for most of the stuff I do and I clear them before exit.

 

Posting my code would be a huge file, so no, I won't be posting that. Not to mention, I'm wanting to publish this game.

 

Could it be an antivirus thing?


mhagain, I'll try that when I get home. it may be the problem.

Share this post


Link to post
Share on other sites

I had this happen recently in an game I was writing in VS 2015. I was getting strange crashes in the middle of a procedural generation algorithm using std::stack. I was accessing memory in a way that caused the program to crash. Most of the time I could stop debugging and the program would exit fine. However, there would be random times where VS would get stuck doing something and not allow the program to shut down, even under Task Manager, forcing me to close and restart VS.

 

I do not have a solution, as mine involved finding and fixing the memory access bug and this is something in how VS starts and runs applications. I would hazard a guess that you're writing to memory somewhere you shouldn't and VS is having trouble as a result, but that is just a guess.

Edited by MarkS

Share this post


Link to post
Share on other sites

Let me be more specific in the sequence of events:

(I run this in "release")

I make changes to my code and compile.

I run the program to see if the changes did what I expected (sometimes it's not what I expected).

I exit the program and it dumps out to the compiler normally.

I make more changes.

I go to compile and that's when it tells me it can't write to the .exe   <---

After a while (less than a minute), I can try to compile again and it works normally.

 

I suppose it's possible that I am not deallocating memory, but I use "vector <>" for most of the stuff I do and I clear them before exit.

 

That is a VERY different problem.

 

There are two common problems that trigger Visual Studio complaining that it cannot open the executable.

 

 

 

The first common cause is that it is trying to embed an application manifest into the executable. You can try turning off the feature in the project's manifest tool settings.  

Basically this is a race condition, the system already has the file open for writing as it wrote out the file, then as it is finishing up another task tries to open the file to embed the manifest.  It is possible for the first task to still have the file open for writing (or for the OS to not have released the file for writing) when the second task tries to open the file. Generally a file can be opened by many readers but only one writer. When it happens, you get the error that writing failed.  Turning off the manifest embedding task avoids the error.

 

 

The second common cause are similar race conditions with the Visual Studio debug host application.  You can turn off Visual Studio Hosting Process in the project's debug settings.

 

The debug hosting tool works like a bridge between your application and the debugger, but can get into a similar race condition.  There are times when the hosting process is helpful, such as when the application uses OS-provided security and trust domains. It can also speed up attaching the debugger by a few seconds. You almost certainly aren't using those features. This can trigger the race condition when you tell the IDE to build and debug -- like the hotkey F5 -- and the build task has not released the file writer when the task host tries to also open the file for writing.  Turning off the hosting process avoids the error.

 

 

 

There are other possible causes, of course.  A virus scanner is probably not the culprit, because generally they open the file for reading. They also tend to prefer opening a shadow copy for reading so it doesn't interfere with another process writing the file and can still open files when an application claims they are locked, but that is a more advanced topic.  It probably is not a virus scanner program, unless it is a particularly bad one.

Edited by frob
I can grammar

Share this post


Link to post
Share on other sites

A backup service like Crashplan will open a file and lock it during the upload. So that's a potential cause.

Share this post


Link to post
Share on other sites

Is your application or any of the libraries that you are using spawning threads? Sometimes if you close the main thread while there are background threads running you might experience a long pause after shutting down until those threads are cleaned up properly.

 

 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!