doublemax wrote: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?

What do you mean with connected?
We just overwrote the wxPanel onPaint() method:

doublemax wrote: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.

Yea, our application has one small window for main settings, a button to open an advanced settings dialog and a button to start the test.
The test progress is shown in another two windows, one dialog with a progress bar and a label telling the current test step.
The second window shows test logs and further test details.

I tried as you told me but no paint event entered the onPaint() code i previously posted here.
When I resize the windows a onPaint() event reaches my code.

I'm not used to use Dr. Memory specially, but according to their doc, it's not necessary relevant talking about recent Windows version: http://drmemory.org/docs/page_gdi.html (and in their topics -- at left side of the help pages --, it seems they separate memory leaks and GDI usage errors). So, maybe trying different analysis tools will help to figure out the point(s) of failure by crosscheck...

Last edited by eranon on Mon Sep 18, 2017 9:35 pm, edited 2 times in total.

It's suspicious that the problem lies in the wxNotebook paint event handler. Do you have any class that derives from wxNotebook?

Seeing this, it's even possible that this is a bug in wxWidgets which has been fixed many years ago. Have you ever tried to compile your project under wx 3.1.x? Or did you just assume that it's a lot of work?

For a test, disable the paint event handler in SettingsGridPanel and check if the leak still exists. If yes, we've been searching in the wrong spot all the time.

If it can help determining if the info is relevant or not, running Dr. Memory (1.11) against one of my own apps (launching the program, then exiting immediately), I got "13 total GDI usage errors" whose 12 about wxToolTip and one about wxNotebook:

eranon wrote:If it can help determining if the info is relevant or not, running Dr. Memory (1.11) against one of my own apps (launching the program, then exiting immediately), I got "13 total GDI usage errors" whose 12 about wxToolTip and one about wxNotebook:

Thanks. So it's possible that the errors in the wxNoteBook paint event handler are not relevant after all. This is getting more confusing all the time.

To OP: If you can't provide a sample that demonstrates the issue, i can only recommend to start commenting out parts of your code that deal with GDI objects until you've narrowed down the code location.

If you can't post relevant code publicly, you can also PM me. Maybe we can figure something out.

Thanks for your suggestions doublemax and eranon (especially for the Dr. Memory testing).
First your questions:

Do you have any class that derives from wxNotebook?

yes, but there are too many to show them all here

Have you ever tried to compile your project under wx 3.1.x? Or did you just assume that it's a lot of work?

We tried, but got many linking errors. I think I can remember because of an wxWidgets API change.

For a test, disable the paint event handler in SettingsGridPanel and check if the leak still exists.

We did that and testing is still going on. We cant yet say it solved the problem, but the error has not occured yet.

To OP: If you can't provide a sample that demonstrates the issue, i can only recommend to start commenting out parts of your code that deal with GDI objects until you've narrowed down the code location.

We do not know under what circumstances the error happens, so I can not provide a sample.

As said we are testing with some paint events commented out. I´ll give you feedback as soon as possible.
The GDI- and User-Object monitoring is implemented, but since that we did not have a crash, so I still can not say that it is a GDI- User-Object leak.

You said you got an increase of GDI handles when you opened end closed the settings window. Shouldn't the change be visible immediately ?

Yea, that is true, but that was just a test to check if there is a leak somewhere in general.
Our guess is that there might be a leak in the progress panel or our log-output panel, but it only happens sporadically.
There is no leak on short test runs, only on long Test runs (1 hour per test cycle for about a week).

When I looked at your stack trace in the OP, it struck me as being very similar to what you would expect to see when you perform GUI tasks in a function that is called from a thread outside of the GUI context.

And then I saw

doublemax wrote:

What do you mean with connected?
We just overwrote the wxPanel onPaint() method:
...
no paint event entered the onPaint() code i previously posted here.

wxWidgets event handlers are not implemented by overriding virtual methods. This method can have any name, there must be either a static event table or a Connect() call somewhere.

Which leads me to think that, potentially, since your onPaint code wasnt properly connected to the event loop, your "this" pointer may lie outside of the GUI context, so you wind up with intermittent exceptions when trying to Ref and UnRef the GUI objects.