I've come across an inexplicable error in SDL 2.0.3 when using hardware rendered graphics. For some reason, around 5 minutes after the program starts my graphical window closes but my console window stays open. There is no error thrown or anything to signify a problem.
When I pause the debugger, the program puts the breakpoint inside of SDL_RenderPresent(). I followed the call stack to a function inside of ntdll.dll called WaitForSingleObject() but I'm not sure what's causing it to hang forever.
Also, this does not happen when I use software rendered graphics. I am running it on an AMD FirePro M5100 FireGL V with the latest drivers installed.
My question is, does anyone know what might cause SDL_RenderPresent() to never return?
From the description seems that there are locks not released by the lower levels of the graphics pipeline.
From the fact that it happens after 5 minutes seems that there is a resource leak somewhere.
All of this is just a wild guess of course, but I'd say that either the application code or the SDL code is leaking resources (handles to textures, vertex buffers and the like) and that part of the code (either at the lower levels of SDL or in the driver) when running out is not behaving nicely (this happens often... in many cases low-resource conditions are not very well tested and handled).
This doesn't happen in software rendering because there resources are basically unlimited. A confirm of this kind of problem would be that when running in software rendering the program works but process memory use keeps growing and growing.
Pay attention also to any code that "catches" any exception/failure and keeps running after that. Writing complex software that works correctly after an abnormal state is extremely difficult (basically impossible beyond trivial cases because exception safety doesn't scale by composition: the only way that doesn't make the complexity explode is to have logical partitioning "walls" and re-initialize whole subsystems).
Related
I have been working for 2.5 years on a personal flight sim project on my leisure time, written in C++ and using Opengl on a windows 7 PC.
I recently had to move to windows 10. Hardware is exactly the same. I reinstalled Code::blocks.
It turns out that on first launch of my project after the system start, performance is OK, similar to what I used to see with windows 7. But, the second, third, and all next launches give me lower performance, with significant less fluidity in frame rate compared to the first run, detectable by eye. This never happened with windows 7.
Any time I start my system, first run is fast, next ones are slower.
I had a look at the task manager while doing some runs. The first run is handled by one of the 4 cores of my CPU (iCore5-6500) at approximately 85%. For the next runs, the load is spread accross the 4 cores. During those slower runs on 4 cores, I tried to modify the affinity and direct my program to only one core without significant improvement in performance. The selected core was working at full load, though.
My C++ code doesn't explicitly use any thread function at this stage. From my modest programmer's point of view, there is only one main thread run in the main(). On the task manager, I can see that some 10 to 14 threads are alive when my program runs. I guess (wrongly?) that they are implicitly created by the use of joysticks, track ir or other communication task with GPU...
Could it come from memory not being correctly freed when my program stops? I thought windows would free it properly, even if I forgot some 'delete' after using 'new'.
Has anyone encountered a similar situation? Any explanation coming to your minds?
Any suggestion to better understand these facts? Obviously, my ultimate goal is to have a consistent performance level whatever the number of launches.
trying to upload screenshots of second run as viewed by task manager:
trying to upload screenshots of first run as viewed by task manager:
Well I got a problems when switching to win10 for clients at my work too here few I encountered all because Windows10 has changed up scheduling of processes creating a lot of issues like:
older windowses blockless thread synchronizations techniques not working anymore
well placed Sleep() helps sometimes. Btw. similar problems was encountered when switching from w2k to wxp.
huge slowdowns and frequent freezes for few seconds on older single threaded apps
usually setting affinity to single core solves this. You can do this also in task manager just to check and if helps then you can do this in code too. Here an example on how to do it with winapi:
Cache size estimation on your system?
messed up drivers timings causing zombies processes even total freeze and or BSOD
I deal with USB in my work and its a nightmare sometimes on win10. On top of all this Win10 tends to enforce wrong drivers on devices (like gfx cards, custom USB systems etc ...)
auto freeze close app if it does not respond the wndproc in time
In Windows10 the timeout is much much smaller than in older versions. If the case You can try running in compatibility mode (set in icon properties on desktop) for older windows (however does not work for #1,#2), or change the apps code to speed up response. For example in VCL you can call Process Messages from inside of blocking code to remedy this... Or you can use threads for the heavy lifting ... just be careful with rendering and using winapi as accessing some winapi (any window/visual related stuff) functions from outside main thread causes havoc ...
On top of all this old IDEs (especially for MCUs) don't work properly anymore and new ones are usually much worse (or unusable because of lack of functionality that was present in older versions) to work with so I stayed faith full to Windows7 for developer purposes.
If none of above helps then try to log the times some of your task did need ... it might show you which part of code is the problem. I usually do this using timing graph like this:
both x,y axises are time and each task has its own color and row in graph. the graph is scrolling in time (to the left side in my case) and has changeable time scale. The numbers are showing actual and max (or sliding avg) value ...
This way I can see if some task is not taking too much time or even overlaps its next execution, peaks are also nicely visible and all runs during runtime without any debug tools which might change the behavior of execution.
I made a basic opengl program and opened it up and I was only getting 2400fps with dips to 700fps in release mode, and I was really confused so I took out everything in the main loop till the code looks like below
while (true)
{
glfwSwapBuffers(window);
}
and now I'm only getting 3400-4000fps (I switched to release mode).
For a bit of context, I've made a game in DirectX 11 where when nothing is drawing it gets 8000fps and that's with input and game logic not an empty loop.
I've tried compiling my own glfw and using precompiled binaries. Im thinking that maybe I need to figure out how to build glfw as apart of my project so I can get more optimization.
I'm really confused, I want to do some heavy stuff in this game but i'm already getting 2-4x less performance when nothing is going on.
Last second addition:
People have talked about glfwswapbuffers having low performance on other threads but in all those cases they are using vysnc. (im using glfwSwapInterval(0))
There might be a multiple reasons to impact the performance of glfwSwapBuffers. Since it works asynchronously, performance might be reduced by synchronizations as v-sync, or monitor refresh rate (60Hz?). Usually you want your engine to be in sync with other processes (even if they are a limiting factor). You might also want to try glfwSwapInterval(0).
I have a C++ program written together with QT5.3.2 + VTK 6.1. The program compiles fine and can run after deployment. Each function button also works fine.
The problem happens when I run this program for weeks (its a motion control software, so it needs to be on for a long time). Randomly(probably not random at all...) it quits/crashes without a frozen window. In another word, the program window just closes and no error message window appears.
I met the memory leak issue before, the program window first froze and the cursor kept busy status and unresponsive. But this time it just closes itself without any error message or unresponsiveness.. Could this also be a memory leak issue?
So I really appreciate it if someone can give me some hint or direction to troubleshoot this issue by their rich experience in programming.
Since there is a lot of code and I do not know where the problem comes from. I will not post code for now but I am happy to include some key aspects:
It uses ADS communication to communicate with hardware drives.
Callback function to fetch the monitoring data and display in QT interface, meaning a lot of actions like LineEdit->SetText() are used repeatedly. SetText() is called with a global qapplication pointer *tp->SetText().
VTK just displays the 3D data. And I separately tested there is no memory leak.
I am happy to share more information if needed.
Memory leak test.
I have written an app in C++ from Visual Studio 2008, running on Windows 7, that runs fine, using either the debug or release versions, when under the control of the debugger, but when running standalone, using either the debug or release versions, it also runs fine except whenever I click on any unrelated window, say a file explorer window, whereupon the app hangs without any warnings from Windows, I see the little circle thing.
The code is doing something rather computationally intensive, accessing data from a 10Mb global array, and it is well within the 2Gb limit of 32 bit Windows. I have checked for the obvious things, such as uninitialized variables, infinite loops, and the like, I am not allocating any big local arrays, but have found nothing wrong. The code is running directly from the UI thread, blocking, but I do not care as there is nothing else to do till that task completes. Alternatively, I could put this code in its own worker thread communicating back to the UI thread by an interlocked buffer, but this seems redundant. I've tried this on two different machines running Windows 7 and get identical behavior. Is there something about Windows process management that I am overlooking? Is there a way to tell whether there is some sort of memory corruption going on that could cause some other process to affect the app's process?
[Edit1 by spektre] just copied user3481340's code from comment to be readable
I do not think that the computational time, which is about an hour
has anything to do with the problem.
Rather, the windows messaging for the edit box is getting messed-up.
The relevant code is:
int textlen=GetWindowTextLength(Editwin);
int k=strcspn(messagebuf,"\n");
if(k<strlen(messagebuf))textlength=strlen(messagebuf)-k;
else textlength+=k;
SendMessage (Editwin, EM_SETSEL, (WPARAM)textlen, (LPARAM)textlen);
SendMessage (Editwin, EM_REPLACESEL, 0, (LPARAM) messagebuf);
Somehow Windows stops responding to these messages.
Windows7 has some changes (from previous versions of windows)
in process scheduling
which can mess up lock-less multi-thread apps which are working 100% thread safe on older versions of windows. There is not much to do with this (unless add some safety sleeps or locks)
critical sections
I am not 100% convinced that critical sections work properly on Win7SP1 as I have some issues on specific machine setup where they do not work with combination of:
heavy duty USB HS bulk data transfers
OpenGL use
multi-threading with heavy multiple critical sections use
but it could be a hidden bug or messed-up Windows7 installation or even HW error
WindowProc
if your message loop get stuck for a longer time then it should then it will cause the program to be detected as non-responding even if it is not. Usually run in compatibility for XPSP3 helps but sadly not on all machines or all apps :( this is the main reason why many games does not run on Win7
I suspect this is your case and according to your last comment I was right.
Transfer critical processing to some thread instead so the WindowProc is not blocked. If you need an event after computation is done then flag some variable as done and scan for it in some timer so you can respond inside main thread (to avoid winapi calls outside main thread).
32bit Driver+App use on x64 windows (WOW64)
if your app is accessing any driver then on WOW64 you need special driver build to access real hardware instead of emulated by WOW64 !!! If you did not then your App is most likely waiting for real device respond instead is getting emulated one which can be different and cause real hang ups. In that case you need compile your app as x64
Or use some kind of WOW64.x86 -> x64 bridge
Or use driver which can handle it itself (usually link do different dll)
The overall program is too complex to display here. Basically, just pay attention to the green highlights in my recent git commit. I am very new to DirectInput, so I expect I've made several errors. I have very carefully studied the MSDN documentation, so I promise I'm not just throwing this out there and stamping FIX IT FOR ME on it. :)
Basically, I think I have narrowed down my problem to the area of code around Engine::getEvent (line 238+). I do not understand how these functions work, and I've messed with certain pieces to achieve different results. My goal here is to simply read in keyboard events directly and output those raw numbers to the screen (I will deal with the numbers' meaning later). The problem here relates to KEYBOARD_BUFFER_SIZE. If I make it small, the program seems to run fine, but it outputs no events. If I make it big, it runs a bit better, but it starts to slow down and then freeze (the OpenGL window just has a rotating color cube). How do I properly capture keyboard events?
I checked the return values on all the setup steps higher in the code. They all return DI_OK just fine.
Your code seems to be okay (according to this tutorial, which I have used in the past). The use of several stack-based arrays is questionable, but shouldn't be too much of an issue (unless you start having lots of concurrent getEvent calls running).
However, your best bet would be to stop using DirectInput and start using Windows Raw Input. It's best to make this switch early (ie, now) rather than realise later on that you really need to use something other than DI to get the results you want.