Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Regards to setActive(bool) and sf::Thread  (Read 4334 times)

0 Members and 1 Guest are viewing this topic.

Catbeard

  • Guest
Regards to setActive(bool) and sf::Thread
« on: January 26, 2015, 01:10:13 am »
In searching for a possible memory leak I have encountered and isolated, I came across this forum topic: http://en.sfml-dev.org/forums/index.php?topic=10309.0

It was said that the memory leak involving the setActive(bool) function was because SFML cannot tell if a std::thread were to end, thus resulting in the memory still being allocated.
I am creating a sf::Thread that takes the handle of handle of the openGL context by called setActive(true), then releasing it with setActive(false), and finally ending.
Every time this thread gets called, it results in ~5.68MB increase in private memory, and ~0.2MB increase in virtual memory on the process.

Is this a relating problem? If so, then why doesn't SFML free the memory when the thread ends? SFML should be able to determine when it does.

Copy and paste-able example:
void secondMain(sf::RenderWindow* renderWindow){
        renderWindow->setActive(true);
        renderWindow->setActive(false);
}

int main(int argc, char **argv) {
        sf::RenderWindow renderWindow;
        renderWindow.create(sf::VideoMode(800, 600), "Text");
       
        sf::Thread thread(secondMain, &renderWindow);
        renderWindow.setActive(false);
       
        while(renderWindow.isOpen()) {
                sf::Event evt;
                while(renderWindow.pollEvent(evt)) {
                        switch(evt.type) {
                        case sf::Event::KeyPressed: //press a key to see the memory increase
                                thread.launch();
                                thread.wait();
                                break;
                        case sf::Event::Closed:
                                renderWindow.close();
                                break;
                        default:
                                break;
                        }
                }
        }
}
 

I am using the latest GitHub version of SFML, running on Windows 8.1. Compiling with MinGW-64 (GCC 4.9.2 x86_64-posix-sjlj-rev0). If any further information is required, please notify me.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
AW: Re: Regards to setActive(bool) and sf::Thread
« Reply #1 on: January 26, 2015, 06:59:31 am »
Is this a relating problem? If so, then why doesn't SFML free the memory when the thread ends? SFML should be able to determine when it does.

You are aware that you've answered your question yourself, right?

It was said that the memory leak involving the setActive(bool) function was because SFML cannot tell if a std::thread were to end, thus resulting in the memory still being allocated.

There are/were workarounds being worked on. If you're really concerned you should try to reduce the amount of threads you create.
Besides it's not an actual memory leak, the freeing of memory is simply delayed till the end of execution. ;)
« Last Edit: January 30, 2015, 06:02:54 pm by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Catbeard

  • Guest
Re: Regards to setActive(bool) and sf::Thread
« Reply #2 on: January 26, 2015, 08:22:32 pm »
You are aware that you've answered your question yourself, right?

My problem is with SFML not freeing the memory when the sf::Thread has ended, not std::Thread.

Thank you for your reply.

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: AW: Re: Regards to setActive(bool) and sf::Thread
« Reply #3 on: January 30, 2015, 05:42:11 pm »
Besides it's not an actual memory leak, the freeing of memory is simply delayed till the enx of execution. ;)
This comment puzzles me eXpl0it3r. How is that not an "actual leak"?
All operating systems that I know of free all resources (including memory) a program allocated when the process terminates. It is not possible to leak beyond the end of the process (if it is, you should file a bug report against your OS vendor). It thusly follows that all leaks occour within the lifetime of the process. Thus, saying that it is not a "real leak" since it will be cleaned up when the process terminates is nonsensical.
What, then, would constitute a "real" leak in your opinion?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
AW: Re: AW: Re: Regards to setActive(bool) and sf::Thread
« Reply #4 on: January 30, 2015, 06:02:27 pm »
This comment puzzles me eXpl0it3r. How is that not an "actual leak"?
All operating systems that I know of free all resources (including memory) a program allocated when the process terminates. It is not possible to leak beyond the end of the process (if it is, you should file a bug report against your OS vendor). It thusly follows that all leaks occour within the lifetime of the process. Thus, saying that it is not a "real leak" since it will be cleaned up when the process terminates is nonsensical.
What, then, would constitute a "real" leak in your opinion?
The difference is, that it is clean up by the process and not the OS.
If you don't call delete on allocated memory or never release OS resources, you create a memory/resource leak, which if the OS doesn't deal with it properly can cause issues for other applications.
But if you just keep allocating memory/resources and explicitly free them at the end of your application, it's not technically a leak.
Of course it's bad memory/resource management regardless.

Anyways I can't say for certain what case here is, but seeing a rising number in the task manager doesn't mean there has to be a technical leak. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: AW: Re: AW: Re: Regards to setActive(bool) and sf::Thread
« Reply #5 on: January 31, 2015, 04:44:30 pm »
... you create a memory/resource leak, which if the OS doesn't deal with it properly can cause issues for other applications.
That would be an OS bug.
If your application terminates but resources are left allocated, causing problems for other apps, then your OS is buggy - plain and simple.
« Last Edit: January 31, 2015, 04:57:55 pm by Jesper Juhl »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
Re: AW: Re: AW: Re: Regards to setActive(bool) and sf::Thread
« Reply #6 on: January 31, 2015, 05:01:27 pm »
That would be an OS bug.
If your application terminates but resources are left allocated, causing problems for other apps, then your OS is buggy - plain and simple.
So why do we even care about releasing memory and resources? The OS will take care it anyways. Right? ;D
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Regards to setActive(bool) and sf::Thread
« Reply #7 on: January 31, 2015, 05:09:16 pm »
When the application terminates, yes.
It can actually be a completely valid optimization to sometimes "leak" resources to facillitate faster shutdown. I've worked on an application that had its own custom database where shutting down could take minutes due to destructors flushing gigabytes of data to spinning rust. In some cases you don't care and just want to shut down fast, so you short-circuit the dtors and "leak" since the OS will then just throw out the objects.
The reason we care is resource use during the run time off the application.  If you leak 10MB memory every 5 seconds, then you are going to run into trouble fairly fast - as an example.  You care about leaks since they may impact your app (or other apps) while it is running. Once the OS has terminated the app such concerns are irrelevant.