Possible GDI Object Leak AIO-5.2.0-r1-54cc357

Development Beta Testing
1

GrampsAIO-5.2.0-r1-54cc357_win64
Windows 11
Clean installation.

I’ve observed very long running gramps 5.1.x sessions eventually crash. I’ve long suspected this could be a GDI handle leak as, just before crashing, new gramps dialogs (e.g. person editor) start rendering with some or all child controls missing.
I believe I can now reproduce a GDI handle leak in the 5.2.0 beta release.

Steps to reproduce

  1. create a new family tree
  2. add a new person. Set the Given name to “Test”. Leave the gender Unknown
  3. Close gramps. Restart gramps. Load the family tree [I’m not sure this step is strictly necessary]
  4. Go to the People page.
  5. Highlight the “Test” person.
  6. Start Windows Task Manager. Change to the Details tab. Right click the header bar of the processes list and choose “Select columns”. Tick the “GDI objects” entry. Click OK
  7. Find gramps.exe in the Task Manage processes list.
  8. Make a note of the GDI objects count
  9. Press the enter key to display the person editor dialog
  10. Press Esc key to close the person editor dialog
  11. Repeat steps 9 and 10 multiple times e.g. 50 times
  12. In Task Manager, look at the gramps.exe GDI objects count
  13. Leave gramps running for a while (e.g. 10 minutes) without any user input. Observe that the GDI objects count has not materially changed, demonstrating that, at least within 10 minutes, the python GC does not free the GDI objects.

At step 7, I had a GDI object count of 156. At step 12, this had increased to 1,130. Your numbers may vary. The relevant point is the significant increase in GDI object handles held by grmps.exe.
Windows has a default limit of 10,000 handles per process.

During the test, memory use also increases, by around 50MB for me. However I do not believe that is the direct cause of the crashes that I’ve observed.

1 Like
2

You can run Gramps without the “-O” option and then use the “Uncollected Objects” gramplet to look for memory leaks.

1 Like
3

I’ve run gramps without -O (this seems to be the default for the start menu entry “GrampsAIO64 5.2.0-console”). The Tools > Debug menu was shown in Gramps
I repeated my experiment. The “Uncollected Objects” gramplet reports 0 uncollected objects (I did press the refresh button both before and then again after the test). Task manager did show the GDI objects count increased for gramps.exe

1 Like
4

I’ve done a bit more digging into this problem. Here’s what I’ve found:

  1. The leaking GDI object are bitmaps and device contexts (DCs).
    It looks like 5 of each type are leaked for each invocation of the EditPerson dialog
  2. Disabling the creation of the SurnameTab object in EditPerson seems to stop the handle leak

Is it valid to call self.track_ref_for_deletion(“surntab”) ?
If I do so the I get uncollected object reported

1 Like
5

A framework for fleshing out a ‘memory leak’ troubleshooting workflow has been created. The initial framework is written (by ChatGPT) at a non-technical 5th grade reading level because the steps are going to be complex enough by themselves.

Let’s put a pin in documenting the workflow until after 5.2 though.

https://gramps-project.org/wiki/index.php/Isolating_Memory_Leaks

6
  • Press the enter key to display the person editor dialog
  • Press Esc key to close the person editor dialog
  • Repeat steps 9 and 10 multiple times e.g. 50 times
  • In Task Manager, look at the gramps.exe GDI objects count

Can you reproduce it by disabling the embedded “Gallery Tab” gramplet?
If you cannot, this could be related to bug report 12289.

7

Looking at (all) cryptic comments pushed on a related bug report (history of the above bug report), maybe two additional links might be useful for your issue: