Console App Does not Create Window on Xcode because "flock failed to lock maps file: errno = 35"

[NotVeryGoodAtCodingButOk]

I followed SFML's setup tutorial, correctly installing SFML on my mac, but the problem is that when I try to run a basic program, I get the following console message "flock failed to lock maps file: errno = 35". Also, the application has a part that declares if the escape key is pressed, it will close the window. Whoever, this does not happen and the app does not respond (Meaning I always have to force quit it)*.

I am using MacOs Catalina (V10.15.5) on a 2016 MacBookPro with 4 thunderbolt ports. Latest version of SFML. Latest version of Xcode.

I investigated on this issue and saw that it may be related to 2 instances of the same app running at the same time, so I restarted my computer to stop all the instances of the app. I even used the Activity Monitor to stop all things that may be related to this app, and cleared the project build inside of Xcode. This, whoever, did not solve it, and as such I need some help.

The code I am trying to run is found on a file named "Timber.cpp", and is below.

//  Timber.cpp
//  Timber!!!
//  Include important libraries here

#include <SFML/Graphics.hpp>

//  Making the code easier to type with "using namespace"
using namespace sf;

//  This is where our game starts from
int main()
{
    //  Create a video mode object
    VideoMode vm(1920, 1080);
    
    //  Create and open a window for the game
    RenderWindow window(vm, "Timber!!!", Style::Fullscreen);
    
    while (window.isOpen())
    {
        /*
         *************************************************************************************************************
         Handle the player's input
         *************************************************************************************************************
         */
        
        if (Keyboard::isKeyPressed(Keyboard::Escape))
        {
            window.close();
        }
        /*
        *************************************************************************************************************
        Update the scene
        *************************************************************************************************************
        */
        
        /*
        *************************************************************************************************************
        Draw the scene
        *************************************************************************************************************
        */
        
        //  Clear everything from the last frame
        window.clear();
        //  Draw our game scene here
        //  Show everything we just drew
        window.display();
    }
    
    return 0;
}

If this helps, here are other warnings/error messages that appeared in the console.

The requested video mode is not available, switching to a valid mode
2020-06-18 09:57:40.859373-0500 Timber[41020:717244] Metal API Validation Enabled
2020-06-18 09:57:40.920899-0500 Timber[41020:717296] flock failed to lock maps file: errno = 35
2020-06-18 09:57:40.922286-0500 Timber[41020:717296] flock failed to lock maps file: errno = 35
2020-06-18 09:57:41.046476-0500 Timber[41020:717244] [default] 0x10000569f: TCC deny IOHIDDeviceOpen
2020-06-18 09:57:41.046762-0500 Timber[41020:717244] [default] 0x1000056cb: TCC deny IOHIDDeviceOpen
2020-06-18 09:57:41.046854-0500 Timber[41020:717244] [default] 0x1000056cb: TCC deny IOHIDDeviceOpen
We got a keyboard without any keys (1)
2020-06-18 09:57:41.046921-0500 Timber[41020:717244] [default] 0x10000569f: TCC deny IOHIDDeviceOpen
We got a keyboard without any keys (1)
(lldb)

*Footnote: this error only happens when I execute the code inside of Xcode, not when I copy the app and run it as any other app (From my desktop)

[eXpl0it3r]

Is it actually crashing or does it just print that information in the console?

As for your code and the other message:

• You really should have an event loop, otherwise the OS may consider your application as "unresponsive"
• You probably have to grant keyboard permission for your application in order to use sf::Keyboard::isKeyPressed()

[NotVeryGoodAtCodingButOk]

Hello, @eXpl0it3r! The problem is that the app does not create a window, which according to my book, it should. I will try to implement an event loop, because of your suggestion. And yes, I already granted permission to the app to use my keyboard :)

[eXpl0it3r]

@NotVeryGoodAtCodingButOk Is this still an issue? I'm not experiencing any issues on Big Sur.

[spilth]

I am experiencing this on Big Sur.

If I add the following before the Keyboard::isKeyPressed check, suddenly the window will appear and the game works:

 while (window.pollEvent(event)) {
    switch (event.type) {
        case Event::Closed:
            window.close();
            break;

        default:
            break;
    }
}

I'll see if I can't put together a small example repo that shows what does and doesn't work.

[spilth]

Okay, here's an example repo with a good example that works (a window with a circle inside opens) and a bad example that doesn't work (no window opens): https://github.com/spilth/sfml-issue

[eXpl0it3r]

Thank you for the test cases! 🙂

You're required to have an event loop, but it's surprising to me that the window doesn't even appear if you don't have one.

@NotVeryGoodAtCodingButOk make sure you add an event loop.

Personally, I'd dismiss the issue otherwise, despite the window not appearing. On Windows for example the window will appear, but soon after, you'll get a "Unresponsive" warnings from Windows if you don't handle events. But I'll sound this "issue" with some more people.

[spilth]

I think the real problem is that @NotVeryGoodAtCodingButOk's example comes directly from Beginning C++ Game Programming - Second Edition by John Horton that doesn't seem to acknowledge or address this issue.

The book is from 2019 and uses SFML 2.5.1.

I've submitted errata for the book and linked to https://www.sfml-dev.org/tutorials/2.5/window-window.php

[eXpl0it3r]

Oh thanks for noticing that and reporting it! Sadly Packt has a reputation for having a terrible technical and also language review process, so it's not surprising to me that this was not address before publication...