If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
I am having a simmilar issue as described here viewtopic.php?t=36096.
It sometimes happens after a few hours, sometimes after a few weeks.
Maybe someone knows the issue and can help me.
I am using wxWidgets 2.8.11 statically linked under Windows.
Hard to tell with this little information. As the crash happens at destruction of a wxBrush, my best guess is that you have a GDI handle leak somewhere. Open the taskmanager and enable display for the columns "user objects" and "GDI objects". If one of these increase over time the application should crash when it comes near 10000, which is the internal Windows limit per application.
doublemax wrote:Hard to tell with this little information. As the crash happens at destruction of a wxBrush, my best guess is that you have a GDI handle leak somewhere. Open the taskmanager and enable display for the columns "user objects" and "GDI objects". If one of these increase over time the application should crash when it comes near 10000, which is the internal Windows limit per application.
Thanks, I will have a look on it.
When I open our settings window repeatedly the number of GDI objects increases and as you mentiond the programm crashes with reaching the 10000.
So is there already a leak?
ONEEYEMAN wrote:Hi,
Also, why do you use an outdated version of the library?
You really should upgrade to the most recent 3.1.
Thank you.
We already tried to upgrade, but it seems like wxWidgets has changed so much, that its a really hard task to upgrade.
When I open our settings window repeatedly the number of GDI objects increases and as you mentiond the programm crashes with reaching the 10000.
So is there already a leak?
Yes. Check the use of wxPen, wxBrush, wxBitmap etc. in the paint event handler and make sure they are all destroyed properly.
BTW: How many GDI objects are there initially when the program starts?
ONEEYEMAN wrote:Hi,
Also, why do you use an outdated version of the library?
You really should upgrade to the most recent 3.1.
Thank you.
We already tried to upgrade, but it seems like wxWidgets has changed so much, that its a really hard task to upgrade.
You could migrate smoothly and split the gap: first to wxWidgets 2.9, then to 3.0, and finally 3.1. And knowing wx 2.8, 2.9, 3.0 and 3.1 can co-exist, you can add as many targets as you want in your project and switch as necessary.
I never used 2.8, I started with 2.9. I don't remember clearly my migration from 2.9 to 3.0, but the one from 3.0 to 3.1 generated a lot of warnings (eg. deprecated). So, if Telemotive wanted to directly switch to wxWidgets 3.1, it would be obviously a good idea, but he doesn't seem to be ready... So, my attempt was to convince him and even if all the steps have not the same weight, it's psychologically smoother (because there's not dev only in life, there's psychology too;). What does we go forward or not ? That is the question!
[Ind. dev. - wxWidgets 3.0/3.1 under "Win 7 64-bit, TDM64-GCC" + "OS X 10.9, LLVM Clang"]
Hi,
Unless you are stuck with some kind of government project where there is no reason to update GUI unless absolutely needs to I would suggest to upgrade.
Just follow the documentation - it explains everything (what is deprecated, what changes are incompatible and how to migrate smoothly).
doublemax wrote:Yes. Check the use of wxPen, wxBrush, wxBitmap etc. in the paint event handler and make sure they are all destroyed properly.
BTW: How many GDI objects are there initially when the program starts?
The number of GDI objects is about 160 after the program start, User-Objects are about 190.
I checked the proper destruction of the wxPen, wxBrush and wxBitmap usage and did not find any mistakes.
I have added some code to monitore the GDI and User object usage over time to detect if there is an increase.
Upgrading is no option at the moment, we mainly need to fix this bug.
I am writing a test software where you can do the same test sequence for n times.
You can set the count of cycles and some more settings in a settings page.
I opened and closed the settings page multiple times to check if the GDI objects and User objects increase.
When reaching the 10000 the program crashed like you said.
But the bug I am trying to find does not occur when editing settings, it occurs during the test.
We have a big window writing test information and logs and a status bar shown during the test.
It would be a big conincidence if these two issues weren't related. Can you show the code for SettingsGridPanel::onPaint()?
Is it possible to estimate how many leaked objects you have per paint event? (By how much does the number increase when you show/hide the settings window once?)
I think it's safe to say that there is no memory leak in that paint event code. Also, the number of handles seems almost constant after the window has been shown once. Just to be sure: How is the paint event handler connected?
I assume the settings window is opened above the main window? Does that have any custom paint code? Showing and hiding the settings window will also cause a paint event in the underlying window. Maybe the problem lies there. If yes, you should also see the problem if you just move a window from another application over your main window, so that lots of paint events are generated.