I've done something really weird to sf::Window

[Groogy]

Well I don't understand it. The application is runnable and everything exits fine. Anyway from NOWHERE the destructor for WglContext is run and it tries to run line 103 which is: DestroyWindow(myWindow);

But I destroyed it long time ago, I don't have any window allocated on the stack. Also the call-stack looks really funny. The function called before(and only) the destructor is called 90909090().

I'm probably doing something very funky which makes this happen. It didn't appear before but now it does. All I did was extend my messaging system to make the main thread and renderer thread work more asynchronous. I'll be committing the code to here: https://github.com/Groogy/Ascension/tree/development
Though it's a lot so don't think anyone would want to read trough it. If someone could give me a pointer to as of why this could have happened then that would be great to help me give concerning code.

Misc: Currently working in Visual Studio 2008 with SFML2 in debug mode. SFML is linked statically with the debug libraries and I have defined SFML_STATIC. Since I use static libraries I get this warning:
"Warning   1   warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library   Ascension"
Just in case if it matters.

PS: Also according to the bugger, the WglContext this pointer is not even correct.

[Laurent]

Could you show the entire call stack of all your threads?

[Groogy]

Erhm how do you mean? This happens after main() has returned and the application itself will return 0 like if there were no problem but then suddenly a breakpoints in windows are called. So my rendering thread has ended and my main thread is about to exit I guess. The only thing before the destructor in the callstack is that weird function. And after that is only addresses to points in system dll's.

Anyway the only parts that should be concerning this is: https://github.com/Groogy/Ascension/tree/development/src/app/controllers
The main controller singleton is allocated with new and the rendering window is a member variable of that controller. Of course the main controller controls the main thread which is started together with the application. The rendering controller receives a pointer to the window trough the start signal. It properly set who is active and so on.

[Laurent]

So basically, when and where is your window destroyed?

[Groogy]

In the rendering thread:

Code: [Select]

void RendererController::DeinitTarget()
{
if(myTarget != NULL)
{
myTarget->Close();
myTarget = NULL;
}
}

Anyway I just tried this out at my workstation, works like a charm. But at home I work on a laptop with Intel. That's probably the problem.... Damn so annoying!

[Laurent]

What you can try:
- update your drivers
- don't use threads
- make sure that nothing weird happens at global exit (check your statics and globals)

[Groogy]

- update your drivers

I'll try that when I get home.

- don't use threads

Noo... This is an experiment with threads

- make sure that nothing weird happens at global exit (check your statics and globals)

I don't have any global variables or statics that could do this. Only globals/statics are pointers to singletons.

I'll have to take a deeper look at it when I get home. I encountered the error last night so I couldn't really do a proper try to fix it.

[Laurent]

Noo... This is an experiment with threads

Ok but we haveto find out whether the problem is related to threads or not

[Groogy]

Noo... This is an experiment with threads

Ok but we haveto find out whether the problem is related to threads or not

Yeah I'll try out a single threaded approach when I get home. Should be easy to change to with my current structure.

[Groogy]

Well now at my laptop, I've tried with turning off the threading completely and also no calls to sf::Window::SetActive and it still appears. So weird..

Also I tried cleaning out my main completely and it still happened. Created a new project with minimal code. And it comes up. But if I clean out main completely here it works. Also I think it appeared when I started working with the static library since my drivers don't like the shared ones.

Test project:

Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
sf::RenderWindow window;
return 0;
}

Just to verify that it wasn't the static destructor fault, this didn't work either:

Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
sf::RenderWindow *window = new sf::RenderWindow();
delete window;
return 0;
}

**EDIT**
Also just tried with recompiling SFML and didn't change. Also same thing with latest revision.

[Laurent]

Can you try a previous revision?

[Groogy]

I've tried 1567 and 1570 now. None works. I can try more if you want too.

Or well, do I go any lower then I won't have the Cmake system to rely on.

[Groogy]

Okay this is crazy. Nothing comes up when I run it without a debugger. So it must be visual stuido's debugger here at my laptop that is faulty or something since it worked perfectly at the workstation.