SFML community forums

Help => General => Topic started by: grok on April 23, 2015, 09:05:10 am

Title: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: grok on April 23, 2015, 09:05:10 am

Good day.

I am using the latest SFML from git (commit e0d27358fb9d62fcba96e1d14fa3185ce63668e9) and just caught this error message when the application quits:

Quote

X Extensions:
   Generic Event Extension - First event: 0
   SHAPE - First event: 64
   MIT-SHM - First event: 65
   XInputExtension - First event: 66
   XTEST - First event: 0
   BIG-REQUESTS - First event: 0
   SYNC - First event: 83
   XKEYBOARD - First event: 85
   XC-MISC - First event: 0
   SECURITY - First event: 86
   XFIXES - First event: 87
   RENDER - First event: 0
   RANDR - First event: 89
   XINERAMA - First event: 0
   Composite - First event: 0
   DAMAGE - First event: 91
   MIT-SCREEN-SAVER - First event: 92
   DOUBLE-BUFFER - First event: 0
   RECORD - First event: 0
   DPMS - First event: 0
   Present - First event: 0
   DRI3 - First event: 0
   X-Resource - First event: 0
   XVideo - First event: 93
   XFree86-VidModeExtension - First event: 0
   XFree86-DGA - First event: 95
   DRI2 - First event: 102
   GLX - First event: 104
   SGI-GLX - First event: 104
Unhandled event type: 85
Report this to the SFML maintainers if possible

It occurs only when I create render window with

Quote

sf::Style::Fullscreen

. When I press an ESC it hangs and doesn't close. In order to close it I had to switch to another virtual console (pressing CTRL+ALT+F2) and come back, then it closes and shows that message in the console.
 
It does not occur when I use one of the examples coming with SFML 2.2 though (I changed the Pong program source code to run the fullscreen mode).

I use Ubuntu 14.04.2 LTS 64bit on my notebook, Intel drivers are up-to-date.

According to the message I report it to you :) I'll be glad to give you more information regarding my system setup if you need. Thank you.

ps: some time ago I couldn't run my application in the fullscreen mode on the notebook. I mean, it ran okay, but it produced weird visual glitches, althought I hadn't experienced this problem when quitting. Now the visual glitches are gone (I made no changes in my program's source code since that time), but I have this error message on quit. Maybe it is relevant.

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: binary1248 on April 23, 2015, 10:44:54 am

Hmm... if you say you can run the examples in fullscreen fine, it must be something specific to your own code.

How big is this application (codewise)? Can you post something minimal that causes the same behaviour?

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: grok on April 23, 2015, 11:12:51 am

okay, I manager Pong to hang on quit:

 sf::RenderWindow window(sf::VideoMode::getFullscreenModes().front(), "SFML Pong",
                            sf::Style::Fullscreen);
 

this is my change in the Pong source code. It hangs, yes, but, it does not output any error messages on the console. Sorry, I have forgotten to mention that my application produces those errors in the console randomly. I.e. I might or might not see them at a particular run. So, the behavior is 100% the same, I'd say.

Out of curiosity I printed out all the available fullscreen modes:

Quote

1366x768 BPP 32
1360x768 BPP 32
1280x720 BPP 32
1024x768 BPP 32
1024x576 BPP 32
960x540 BPP 32
864x486 BPP 32
800x600 BPP 32
720x405 BPP 32
680x384 BPP 32
640x480 BPP 32
640x360 BPP 32
1366x768 BPP 24
1360x768 BPP 24
1280x720 BPP 24
1024x768 BPP 24
1024x576 BPP 24
960x540 BPP 24
864x486 BPP 24
800x600 BPP 24
720x405 BPP 24
680x384 BPP 24
640x480 BPP 24
640x360 BPP 24
1366x768 BPP 16
1360x768 BPP 16
1280x720 BPP 16
1024x768 BPP 16
1024x576 BPP 16
960x540 BPP 16
864x486 BPP 16
800x600 BPP 16
720x405 BPP 16
680x384 BPP 16
640x480 BPP 16
640x360 BPP 16
1366x768 BPP 15
1360x768 BPP 15
1280x720 BPP 15
1024x768 BPP 15
1024x576 BPP 15
960x540 BPP 15
864x486 BPP 15
800x600 BPP 15
720x405 BPP 15
680x384 BPP 15
640x480 BPP 15
640x360 BPP 15
1366x768 BPP 8
1360x768 BPP 8
1280x720 BPP 8
1024x768 BPP 8
1024x576 BPP 8
960x540 BPP 8
864x486 BPP 8
800x600 BPP 8
720x405 BPP 8
680x384 BPP 8
640x480 BPP 8
640x360 BPP 8
1366x768 BPP 4
1360x768 BPP 4
1280x720 BPP 4
1024x768 BPP 4
1024x576 BPP 4
960x540 BPP 4
864x486 BPP 4
800x600 BPP 4
720x405 BPP 4
680x384 BPP 4
640x480 BPP 4
640x360 BPP 4
1366x768 BPP 1
1360x768 BPP 1
1280x720 BPP 1
1024x768 BPP 1
1024x576 BPP 1
960x540 BPP 1
864x486 BPP 1
800x600 BPP 1
720x405 BPP 1
680x384 BPP 1
640x480 BPP 1
640x360 BPP 1

But anyway the first mode is correct (my desktop environment uses 1366x768 resolution).

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: binary1248 on April 23, 2015, 02:19:25 pm

Build the example in the debug configuration and run it through the debugger. When it hangs at exit, break and show the backtrace.

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: grok on April 25, 2015, 07:49:46 pm

I cannot break in the debugger when the fullscreen applications hangs at exit, unfortunately. All desktop environment freezes and I cannot get to the gdb session.

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: binary1248 on April 25, 2015, 07:54:39 pm

You can run GDB in another terminal TTY and force the executable to use the primary desktop environment display by setting the DISPLAY environment variable accordingly. You will be able to switch between TTYs like that and be able to control gdb regardless of what happens in your desktop environment.

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: grok on April 25, 2015, 08:56:44 pm

thank you.
I tried your approach. in this case when it freezes and I come back to the tty where the GDB is running, it immediately quits and says something like ".[Inferior 1 (process xxxx) exited normally]".
Also, nothing happens when I set a breakpoint at the line having "window.close();". it ignores it somehow.

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: binary1248 on April 26, 2015, 10:35:20 am

So... what you are saying is that it isn't the SFML application that is locking up but your window manager? If that is the case, we can't really help you much. :-\

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: grok on April 26, 2015, 03:00:28 pm

I hope I don't bother you. Just tested it in Fluxbox Desktop Environment. It hangs :-/

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: binary1248 on April 26, 2015, 03:03:50 pm

Can you test it on another independent system (another computer)? Maybe it has something to do with something that is specific to the system you are on that isn't specific to the window manager (e.g. X server).

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: grok on April 27, 2015, 06:06:30 am

here's the result: it doesn't hang on another computer (Ubuntu 14.0.2, 32 bit, Nvidia discrete GPU).

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: binary1248 on April 27, 2015, 09:31:40 am

Well... if this is specific to that one specific system, I don't really see how we can help you that much. :-\

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: grok on April 27, 2015, 04:31:43 pm

yes, I do understand what you explained.

if it is a bug, it should be fixed, I hope. in other words, say, I have some OpenGL game which runs fine in fullscreen mode, but I cannot say the same about the SFML example. so, there's something wrong with the SFML example, not my "system".

I just don't know where to move on from here. I'd be glad to help the community in fixing this bug.

Title: Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"
Post by: binary1248 on April 27, 2015, 05:16:51 pm

Quote from: grok on April 27, 2015, 04:31:43 pm

in other words, say, I have some OpenGL game which runs fine in fullscreen mode, but I cannot say the same about the SFML example. so, there's something wrong with the SFML example, not my "system".

That's not how it works. I can honestly say, since I've worked with SFML code for quite a while, that SFML does not rely on any undefined behaviour, and if somebody notices it does, it would get corrected as soon as possible. It follows interface and API specifications to the letter. If an interface or API does not behave like the specification requires it to, then we cannot guarantee proper behaviour. Whether the developers of this OpenGL game you are able to run know this and coded a workaround, or whether they just got lucky and don't rely on the same behaviour that SFML does, I do not know.

The fact that in your first post, the log shows that an XKeyboard event is sent to the SFML event loop although we didn't register for any is already non-conforming. The X protocol promises this would not happen, and yet it does, only on your system, so either the version of the X server you have installed is bugged in some obscure way (not unlikely considering X is a buggy mess anyway), or something else that is specific to your system is causing it to malfunction (library dependencies etc.).

Simply saying X works and Y doesn't, so it's definitely Y's fault because they both rely on a common set of dependencies is firstly not fair and secondly not productive. Don't call this a bug, it isn't a bug in SFML until you can prove it properly. Nobody else (so far) can reproduce your issue, and even you can't reproduce your issue on another system. I'm even going so far as to say that if you installed a second copy of Ubuntu on the same machine the problem will disappear as well. You are the one who has to become active and take the initiative and try to isolate the problem since nobody else can. We can always help, but in this case you are going to be the one who has to do the majority of the work.