Most simple pollevent loop breaks program.

[warjo]

Update:
Ok i think this happens every single time i try to build the libraries with MFC in static library or UNICODE char set. At least thats what im only tweaking. VS11/VS12 same thing. I'm not sure why. And actually in release version i get a different error as soon as i hit a key or something:

A buffer overrun has occurred in G5.exe which has corrupted the program's internal state. Press Break to debug the program or Continue to terminate the program.

Ok i need help figuring this out because i've tried every thing the last 2 days.
Basically this simple pollEvent loop can trigger a breakpoint.

        while (this->myWindow->pollEvent(anEvent))
        {
        }

       
And this is the best trace i can get after my HandleInput() method which contains those 3 lines above.

   G5.exe!__crtUnhandledException(_EXCEPTION_POINTERS * exceptionInfo) Line 259   C
    G5.exe!__raise_securityfailure(_EXCEPTION_POINTERS * ExceptionPointers) Line 79   C
    G5.exe!__report_gsfailure() Line 241   C

I really want to get the static linkage down right and also use the pollEvent loop mostly because of its keyRelease functionality (If there is an alternative here i'd be glad to hear it out).

Funny thing is this only occurs in my release build with static linkage. Debug build (with debug libs) works fine and same thing stands true for the shared release build (if i remember correctly)
 I'm really desperate and tried everything. Any clues?

Also some answers to some possible questions:
-I'm using visual studio 2013.
-This happens with visual studio 2012 also.
-I did compile the libraries from the latest build available in github with the proper settings.
(also take note, the one you provide for download in the website seems broken. It fails to load all modules properly in the visual studio after cmake. Tried two different stations. Same results)

I'm available for any further info you might need.

[eXpl0it3r]

You say something about MFC or UNICODE what do you mean exactly?
Since it's obviously not crashing in SFML, what's the rest of your code? Can you provide a minimal but complete example?
Does it crash even if you don't call any SFML functions?
What is "this" in your tiny code extract?

Do you have other libraries? If yes, do you link the right versions? Are you mixing runtime libs (/MT vs /MD etc)?

[warjo]

You say something about MFC or UNICODE what do you mean exactly?
Since it's obviously not crashing in SFML, what's the rest of your code? Can you provide a minimal but complete example?
Does it crash even if you don't call any SFML functions?
What is "this" in your tiny code extract?

Do you have other libraries? If yes, do you link the right versions? Are you mixing runtime libs (/MT vs /MD etc)?

MFC And Character Set settings in visual studio project settings.
I'm afraid i can't provide much code because it's a very big project by now.
Basically this refers to my GameLogic module which takes care of the user input. It gets the sfml window pointer from another module after the window is created. It is this specific snippet of code that causes the crash. If i commend it out this part of code the game runs smoothly (it is a game).
/MT /MD are always the same. No other libraries are used except glew which is static linked. Other sfml calls run without disturbing anything except this part.
Regular input check as

if (sf::Keyboard::isKeyPressed(sf::Keyboard::Space))

works perfectly fine.
Any thoughts?

[eXpl0it3r]

MFC And Character Set settings in visual studio project settings.

That didn't clear anything up. You have to assume that I've no idea what you're talking about (which I really kind of haven't).

I'm afraid i can't provide much code because it's a very big project by now.

That's exactly the point. IF there's a problem with linking related to SFML, it must be reproduceable with a minimal example, that doesn't have all the other clutter. Just go ahead, create a new project, set the settings up the same as in your other project and compile the most simplest SFML code that it similar to the code that causes the crash. If it does crash, you successfully excluded any kind of other code pieces and one can start digging deeper. If it however doesn't crash then it's not really related to SFML or any settings, but probably more the interaction of your code. To see if it's your code, you could then add back it more and more of the code, until you get the crash again.
This here is exactly what more complex debugging is about. It's not guessing blindly and trying a few things, but it's about isolating the problem down to the least possible constrains.

You might as well provide the full build command.

[warjo]

I was just doing that as a matter of fact. Thought this was the only thing i haven't tried so far. Reproduce it with pure sfml code in it. So i started a new project. I'll get back to you with new leads

[warjo]

Ok you were right. In an isolated sfml environment it works without any issues. I still can't understand how it works in anything but static linking.

[eXpl0it3r]

If you want further help with it, you might want to provide more information on your setup and what you're actually doing code wise.

[warjo]

Well the thing is that the debugger is pretty vague here. I wish i had more information so i can debug this properly. Also i tried to remove code segments till i get back to almost nothing and i started noticing some very weird behavior. As i mentioned above it's this segment of sfml code that triggers this buffer overrun(the pollEvent part).

One of the weird things i noticed was something like this:
Say i have my main game loop

This works.

void G5::GameEngine::mainGameLoop()
{
        while (true)
        {
                sf::Event anEvent;
                while(this->myWindow->pollEvent(anEvent))
                {
                }
        }
}
 

This does not. And it makes no sense.

void G5::GameEngine::mainGameLoop()
{
        while (true)
        {
                this->HandleInput();
        }
}


void G5::GameEngine::HandleInput()
{
        sf::Event anEvent;
        while(this->myWindow->pollEvent(anEvent))
        {
        }
}

And if i look into object properties while the breakpoint is called i sometimes may find Access violation errors and stuff.

[Nexus]

Are you debugging in Debug mode with the debug libraries?

Such behavior that makes no sense is often a result of configuration and linking mistakes, or of undefined behavior elsewhere. Make absolutely sure that you follow the official SFML tutorial and don't mix any compiler versions or other configurations such as release/debug.

Then, come up with a complete minimal example -- we have to be sure that the mistake is not triggered somewhere else in your code (which it likely is).

[warjo]

The thing is this doesn't trigger in a debug build (with debug libraries). I haven't tried static debug libraries yet though (if i can compile such version, haven't really looked for it yet). If i can compile sfml in static debug i'll give it a try.

Update:
Apparently i can so i'm going to give this a try and see if i can get more information out of it.

[Nexus]

Saying that it works in some configurations while it crashes mysteriously in others won't really help us... But it's nice if you can debug properly.

Something not unlikely is that your huge code has undefined behavior somewhere. Do you use a lot of error-prone techniques, such as manual memory management, pointer arithmetic, raw arrays etc? If so, you shouldn't. Maybe have a look at such places first, and do it better in the future

[warjo]

Ok so.
Release static -> nope.
Release shared - works
Debug static -> works
Debug shared -> works

I'm hopeless. I think i should focus on the build + sfml compile settings but i'm quite familiar with the procedure. I can't think of something i'm doing wrong. I'm starting to rule out the whole another part of my code triggers this breakpoint. I mean if that was the case shouldn't this be triggered in the other builds as well?

[Ixrec]

If it was triggering the error in a deterministic and well-defined fashion, yes.  But as Nexus pointed out, you might have undefined behavior somewhere in your code, and build settings can certainly change the result of undefined behavior (in fact pretty much anything can; that's why it's called "undefined").

Try removing large chunks of your code until you get more consistent results, or until you get down to a minimal example.  That should help you and us figure out where the problem is.

[Nexus]

I mean if that was the case shouldn't this be triggered in the other builds as well?

No, that's why it's called undefined -- seemingly unimportant factors can change everything. I'm not saying it must be UB in your case, but at least that sounds familiar.

But double-check your configuration first. You mentioned UNICODE and MFC initially... Did you change compiler settings in your project? If so, you may have to do the same in the SFML projects, i.e. rebuild SFML with those settings.

[warjo]

I'm sorry but i'll have to keep insisting it's not "my-code" related but rather a settings / linking type of problem.
I discovered that my release sfml build was compiled with the v110 libs enviroment while my program was with the v120. I noticed this in the dependency walker. Sfml libraries required v110 dlls my program required v120. But it was working. If i go v120 - v120 for some reason it all breaks down. Thing is i managed to find a temporary solution by removing the security check option in my compiler (/GS) after more closely inspecting the call stack..

        msvcr120.dll!_crt_debugger_hook(int _Reserved) Line 60  C
        G5.exe!__raise_securityfailure(_EXCEPTION_POINTERS * ExceptionPointers) Line 70 C
        G5.exe!__report_gsfailure() Line 241    C
 

It's really not like i haven't tried to remove code blocks till i get to a safe point in my program, but really, there is so randomness and unexplained behavior going on in this procedure that no sane person can keep up with it.

I'm not blaming sfml either of course. I'm even assured this problem is on my end but i'm almost convinced it's settings/building/linking problem or something of that nature. One thing that crossed my mind recently is that i switched Visual studio versions mid-project. Do you think this could have anything to do with it?

Also this problem is almost identical to mine:
http://www.dreamincode.net/forums/topic/245418-sfml-render-window-problem/