There is a pattern of Gramps crashing after upgrades on the 1st use of enhanced features. But then the problems cannot be reproduced on demand.
I suspect that this is due to incompatible settings (having been stored in the previous version), overwritten when read the first time, but the enhanced feature cratering because it is intolerant of the incompatible settings.
The .ini reader method seems to work. It reads the data and updates it to the new format. But apparently still feeds the old format data to the module. The next time you run the same test, the problem is a ghost.
How can this theory be tested?
It is important which OS you are having trouble with, if it is on Windows, there is the option to start Gramps from within the installer program. The default option will start a different Gramps executable file that was intended to help debug start-up problems. This will mean that for the 1st-run you are running a slightly different version of Gramps. (see Mantis issue 0012060)
The OS seems to be irrelevant in this situation. (But I have confirmed it in Linus and MS Windows.)
Likewise, the AIO sublauncher seems irrelevant.
0012060: [Windows AIO Installation] make launch from installer same as launch from desktop shortcut
I have crash examples related to an update of an addon with expanded features, not the application. Again, the settings were expanded, and after re-starting Gramps — launching the updated Addon crashed the application. But restarting Gramps, unlocking the tree, reloading and launching the Addon simply works.
When 2 beta tester saw this in some Addons, I added versioning to the .ini file. Made the addon flush reset settings to default if there was no version key. Subsequent beta testers no longer experienced the crash.
I recall experiencing inexplicable and irreproducible crashes after almost every upgrade (not bug fix update) to Gramps. They have been very frustrating because I have been unable to isolate a bug to file.
The .ini files are strictly within the Gramps User Directory. Then read and written solely by Gramps. Some are stored in the gramps.ini; others are in view, sidebar, or bottombar .ini files; and others in destinations specified by the plug-in itself.
I think the core methods for importing settings need some fault handling.
But that theory cannot be validated without some better diagnostics and error logging.
@emyoulation
Given that you might be working with an addon that causes this crash, a way to get a reproducible case would be to:
- Back up your initial settings file before the crash and without the new settings that the addon introduces
- Backup the current version of the plugin folder so you can restore it later
- Update the addon via Gramps, do whatever you do which might result in a crash
- Back up your updated settings file after the crash
- Restore the previous version addon directory and restore your original settings file.
- With the reset state, attempt to make it crash again.
If you can nail it down this way, it would help debug the issue by looking at INI diffs, knowing which addon was upgraded and to which version, and what steps lead to a crash.