Error loop: gramps.gen.errors.HandleError: Handle is None

In 5.2 beta, I did an import into a new tree of a GEDCOM with lots of irregularities to see what the new version does.

(The Import preferences were set to Tag and Source the GEDCOM import. Because it seemed to skip tagging some Note object when importing our sample gedcom and I didn’t see any sources added when importing that either.)

After changing the the tag color from Black to Red (so there would be a visible difference in list views), I tried going to the Note view.

And Gramps got stuck in an error loop:

2023-08-23 02:56:25.260: ERROR: grampsapp.py: line 188: Unhandled exception
Traceback (most recent call last):
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/treemodels/flatbasemodel.py", line 805, in do_get_value
    val = self._get_value(handle, col)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/treemodels/flatbasemodel.py", line 789, in _get_value
    return self.fmap[col](self.prev_data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/treemodels/notemodel.py", line 165, in column_tag_color
    tag = self.db.get_tag_from_handle(handle)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gen/db/generic.py", line 1371, in get_tag_from_handle
    return self._get_from_handle(TAG_KEY, Tag, handle)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gen/db/generic.py", line 1334, in _get_from_handle
    raise HandleError("Handle is None")
gramps.gen.errors.HandleError: Handle is None

2023-08-23 02:56:25.447: ERROR: grampsapp.py: line 188: Unhandled exception
Traceback (most recent call last):
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/listview.py", line 308, in foreground_color
    fg_color = model.get_value(iter_, model.color_column())
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: unknown type (null)

2023-08-23 02:56:25.751: ERROR: grampsapp.py: line 188: Unhandled exception
Traceback (most recent call last):
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/treemodels/flatbasemodel.py", line 805, in do_get_value
    val = self._get_value(handle, col)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/treemodels/flatbasemodel.py", line 789, in _get_value
    return self.fmap[col](self.prev_data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/treemodels/notemodel.py", line 165, in column_tag_color
    tag = self.db.get_tag_from_handle(handle)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gen/db/generic.py", line 1371, in get_tag_from_handle
    return self._get_from_handle(TAG_KEY, Tag, handle)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gen/db/generic.py", line 1334, in _get_from_handle
    raise HandleError("Handle is None")
gramps.gen.errors.HandleError: Handle is None

2023-08-23 02:56:25.937: ERROR: grampsapp.py: line 188: Unhandled exception
Traceback (most recent call last):
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/listview.py", line 308, in foreground_color
    fg_color = model.get_value(iter_, model.color_column())
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: unknown type (null)

2023-08-23 02:56:26.238: ERROR: grampsapp.py: line 188: Unhandled exception
Traceback (most recent call last):
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/treemodels/flatbasemodel.py", line 805, in do_get_value
    val = self._get_value(handle, col)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/treemodels/flatbasemodel.py", line 789, in _get_value
    return self.fmap[col](self.prev_data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gui/views/treemodels/notemodel.py", line 165, in column_tag_color
    tag = self.db.get_tag_from_handle(handle)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gen/db/generic.py", line 1371, in get_tag_from_handle
    return self._get_from_handle(TAG_KEY, Tag, handle)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/districtsupport/Documents/GitHub/Gramps/gramps/gen/db/generic.py", line 1334, in _get_from_handle
    raise HandleError("Handle is None")
gramps.gen.errors.HandleError: Handle is None

Killed

Please supply more detailed step to reproduce this error.

I can import the sample Gedcom with the option to create import tags. Changing the tag colour works fine. I don’t see any errors in the note view.

Yes. The test with sample GEDCOM only skipped sourcing and some tags.

It did not have error parsing that generated exception notes (Notes with the bad data). So that’s why I imported a clean-structured file with unknown GEDCOM field labels.

But the concern really isn’t about what created the bad data in Gramps. The concern is the error loop has no safe exit!

When Gramps starts popping a Report error Dialog and every time you close it, another dialog pops because the view can’t work with that table, there needs to be a bail out option. A way to stop using that view or tree data and exit Gramps cleanly.

Maybe it could count the dialogs in a session and when it gets to a certain number (like 3?), the dialog could offer an extra option to close the tree or exit Gramps entirely?

(Although exiting entirely also closes the console and loses the errors. So that process should tell the user where the error log file is located for their OS.)

I don’t have time to improve our error reporting system before the next release. Please submit a feature request.

Do you get any errors on the commend line that may help?

Can you reproduce the error using the example database?

The data used to create the problem will (and should!) create howls of protest.

To see what happens with importing GEDCOM7 (first howl), I downloaded the Maximal70.gdz GEDZIP archive (2nd howl) from the tools page of the GEDCOM.io site.

Naturally, it did not recognize the archive type so I had to open the archive manually and extract the .ged file. And then the built-in GEDCOM import plugin correctly complained that it was version 7 that it doesn’t know. (I was curious how we were going to handle when someone wrote an updated importer plugin.)

As the last evil twist of the knife, I text edited the .ged file to change to 5.5.1 version. (3rd loudest howl) And imported it.

That generated lots of expected complaint from the importer plugin. They appeared to be handled gracefully.

Then I changed the import tag color and switched to the Notes view.

Agreed, that is the appropriate step.
added 0012986 new • Feature Requests • Cascades of error dialogs need an option to cleanly bail out of Gramps

I need to see if that error condition can be reproduced from scratch, or from the database file. I suspect that exporting a backup in XML will either fix the bad data or have another error loop.

It may be a problem where the data problem is too transitory. So it would be difficult to validate a solution.

Yes. The only problem is that an import tag is attached to a note in the header before the tag is defined.

It is easy to fix.

1 Like

Do you want a MantisBT report?

Yes please. It would be better to have a short report.

added 0012985 new • Gramps • Import of GEDCOM with tags applies tags to error notes before creating the tag
See gramps Pull Request 1540
Fixed in commit 5055e855.

1 Like