pollEvent crash after window re-create (osx)

[moonfirefly]

I get a crash on pollEvent after re-creating the window, immediately after I do a command+tab while moving the mouse or trackpad. It looks like input events are polled on a resource that has been deallocated upon re-creating the window.

Here's a small example that triggers the problem every single time on my macbook with these steps:

• Run example
• Press 'F' key to trigger a window re-create
• Press command+tab to lose window focus while moving mouse/trackpad

Example source:

(click to show/hide)

#include <SFML/Graphics.hpp>

int main(int, char const**)
{
    sf::RenderWindow window(sf::VideoMode(1440, 900), "SFML window");
   
    bool toggle = false;
   
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::KeyPressed) {
                switch (event.key.code) {
                    case sf::Keyboard::Escape:
                        window.close();
                        break;
                       
                    case sf::Keyboard::Key::F:
                        toggle = !toggle;
                        window.create((toggle) ? sf::VideoMode(800, 600) :
                                                 sf::VideoMode(1440, 900), "SFML window");
                        break;
                       
                    default:
                        break;
                }
            }
        }
        window.clear();
        window.display();
    }
   
    return EXIT_SUCCESS;
}
 

The exception as it occurs in Xcode:

(click to show/hide)

The crash log with a test outside Xcode:

(click to show/hide)

Process:         TestWindowCrash [24152]
Version:         0
Code Type:       X86-64 (Native)
Parent Process:  launchd [251]
Responsible:     TestWindowCrash [24152]
Date/Time:       2014-08-23 00:27:21.673 -0400
OS Version:      Mac OS X 10.9.4 (13E28)
Report Version:  11
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT

Application Specific Information:
objc_msgSend() selector name: respondsToSelector:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                     0x00007fff847d40a3 objc_msgSend + 35
1   com.apple.AppKit                    0x00007fff85205af6 -[NSApplication _createDockMenu:] + 137
2   com.apple.AppKit                    0x00007fff85205a2c __44-[NSApplication _copyPublicPersistentUIInfo]_block_invoke + 35
3   libdispatch.dylib                   0x00007fff8ad481bb _dispatch_call_block_and_release + 12
4   libdispatch.dylib                   0x00007fff8ad4528d _dispatch_client_callout + 8
5   libdispatch.dylib                   0x00007fff8ad4cef0 _dispatch_main_queue_callback_4CF + 333
6   com.apple.CoreFoundation            0x00007fff89d8e4f9 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
7   com.apple.CoreFoundation            0x00007fff89d49714 __CFRunLoopRun + 1636
8   com.apple.CoreFoundation            0x00007fff89d48e75 CFRunLoopRunSpecific + 309
9   com.apple.HIToolbox                 0x00007fff8db84a0d RunCurrentEventLoopInMode + 226
10  com.apple.HIToolbox                 0x00007fff8db847b7 ReceiveNextEventCommon + 479
11  com.apple.HIToolbox                 0x00007fff8db845bc _BlockUntilNextEventMatchingListInModeWithFilter + 65
12  com.apple.AppKit                    0x00007fff84fd924e _DPSNextEvent + 1434
13  com.apple.AppKit                    0x00007fff84fd889b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
14  org.sfml-dev.sfml-window            0x000000010cbe5ec3 +[SFApplication processEvent] + 147
15  org.sfml-dev.sfml-window            0x000000010cbea7ef -[SFWindowController processEvent] + 207
16  org.sfml-dev.sfml-window            0x000000010cbdfb03 sf::priv::WindowImpl::popEvent(sf::Event&, bool) + 51
17  org.sfml-dev.sfml-window            0x000000010cbdf116 sf::Window::pollEvent(sf::Event&) + 38
18  TestWindowCrash                     0x000000010cbc2ff0 main + 304 (main.cpp:28)
19  libdyld.dylib                       0x00007fff875ff5fd start + 1
 

The issue occurs even if the resolution is not changed or using different styles. I compiled SFML from source as of today. I did try to re-create the window outside the pollEvent loop but still get the crash at the next pollEvent call.

Note that doing plenty of command+tab and mouse events without window re-creation does not trigger the problem.

Am I doing something wrong here?

[Strelok]

It keeps recreating the window as soon as you press F once.
Toggle must be declared in the is open loop and yes, the window create is (probably?) better off of the poll event loop

[moonfirefly]

It keeps recreating the window as soon as you press F once.

It doesn't, did you run the example?

Toggle must be declared in the is open loop

Toggle in this case is not a trigger, it designates state, thus is outside the loop.

and yes, the window create is (probably?) better off of the poll event loop

As mentioned, I did try this option to no avail and posted the simpler example for simplicity.

Out of due diligence, here's another complete example with the window re-create outside the event loop that still triggers the problem:

(click to show/hide)

#include <SFML/Graphics.hpp>

int main(int, char const**)
{
    sf::RenderWindow window(sf::VideoMode(1440, 900), "SFML window");
   
    bool quit = false;
    bool toggle = false;
   
    while (!quit)
    {
        while (window.isOpen())
        {
            sf::Event event;
            while (window.pollEvent(event))
            {
                if (event.type == sf::Event::KeyPressed)
                {
                    switch (event.key.code)
                    {
                        case sf::Keyboard::Escape:
                            window.close();
                            quit = true;
                            break;
                           
                        case sf::Keyboard::Key::F:
                            window.close();
                            break;
                           
                        default:
                            break;
                    }
                   
                }
            }
            window.clear();
            window.display();
        }
       
        if (!quit)
        {
            toggle = !toggle;
            window.create((toggle) ? sf::VideoMode(800, 600) :
                                     sf::VideoMode(1440, 900), "SFML window");
        }
    }
   
    return EXIT_SUCCESS;
}
 

[Strelok]

You're completely right, I should learn not to lurk the forums while I am only half awake. I apologize for sounding like a smartass and not helping you a single bit  .
Let me try again (I know nothing about OSX but no one seems to reply and I have a lot of time to waste):

• Random (most likely totally unrelated) URL
• Are you compiling in debug or release mode?The code has a lot of error messages and it's weird nothing happens before the crash.

[moonfirefly]

Random (most likely totally unrelated) URL

I have no idea if the autorelease wrapper is in cause or not. Either way I have no control over it.

Are you compiling in debug or release mode?

Compiling in debug or release mode yields to the same result.

The code has a lot of error messages and it's weird nothing happens before the crash.

There's a stack trace in the crash log but there are no error messages, just a general protection fault. On my end at least.

[Hiura]

I just tried the second code sample you gave but could not reproduce the issue.

When you compiled SFML on the 23rd, did you remove any previous binary from your system? Maybe there's a bad mix going on..

EDIT: hum.. in fact I could reproduce it a few times.. but it's very strange... I'll try to have a look.

[Hiura]

After a bit of git bisect I think I found the issue. Can you confirm that replacing line 219 in src/Window/OSX/WindowImplCocoa.mm with

            [NSApp setDelegate:[[SFApplicationDelegate alloc] init]];

fix the issue?

[moonfirefly]

Success! I cannot reproduce the problem anymore, I'll do further tests but it looks good 

It wasn't line 219 exactly but I figured you removed the autorelease.

Here's my exact change:

(click to show/hide)

Thanks a lot!

[Hiura]

Great, thanks for your help. I'll include a patch soon together with issue #672.