[Ubuntu] Resizing a window hangs up app and system

[BlueCobold]

Hey. My game uses resizeable windows and they can be resized properly on Windows and OS X, but when trying to resize them on Ubuntu, everything goes very bad. I pick the window-border, move the mouse a little and the window size changes, *but* a blink later it switches right back to the previous size and even worse, when releasing the mouse-button, the window *keeps* resizing with every mouse move (and switching back and forth) all the time. That results in the app basically hanging up and my system too. Rendering is getting totally messy overall and becoming unresponsive until I kill the app via CTRL+C in the terminal it was launched from. The more I move the mouse, the worse the overall system performance gets.
Any ideas?

[eXpl0it3r]

Are you testing things still in a VM or is it a native system?

[BlueCobold]

VM, but I got same behavior reported from others on native systems.

[eXpl0it3r]

What Ubuntu version, what window manager and which SFML version?

[BlueCobold]

Ubuntu 14.04
Window Manager Compiz (CURRENT_DESKTOP/SESSION -> Unity 3D)
SFML 2.3.2

[Tank]

Please provide a minimal example that reproduces the problem.

[BlueCobold]

The SFML-sample is a minimal example.

[binary1248]

Build both SFML and your application in debug and see if anything shows up on the console. If nothing shows up, you can try using a system profiler to see where the system spends most of its time while running your application.

[BlueCobold]

Can't debug, because it messes up my entire system. I will build in debug and monitor the console and error log when I have the time and report back,

[Jesper Juhl]

Can't debug, because it messes up my entire system.

That sounds like a problem you might want to fix first. Development qithout being able to use a debugger is going to be a pain in the neck going forward.

[BlueCobold]

I can use a debugger in general, but I can't debug this specific bug, because the bug causes my system to get messed up. See the original report in the first comment in this topic.

[binary1248]

Build the application in debug with profiling (gprof) enabled. Let it run a bit, do stuff to your system, then close/kill it. The profiling data should still be saved AFAIK. You can then use gprof to process it and see where most of the time (if any) is spent inside your application and SFML.

If it gets really bad, you can always just SSH into your machine from another and run something like oprofile from the command line while the application is running. Just like gprof, you can process the collected data in peace after you kill the application once you think enough samples have been collected.