YACReader Core Dump

I have a very strange behavior of YACReader in the last 2 days.
- YAC Reader Library works fine, all comics are browseable and importeable from other Desktop or iPad
- YACReader application starts up fine
- If I try to open any file it core dumps:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Abandon (core dumped)

But, if I start it from a different user (one I create for the test) or from root, it works fine
I have tried to remove and reinstall the package but it makes no difference.

So something in my user config (specific YAC or anything else related to gnome) has changed which prevents YACReader from working.
Is there any config file or cache or specific gnome attribute which is not overwritten by package install (like default mimetypes) that could explain the strange behavior?

Thanks in advance for your help
STephane

Note: I use YACReader 9.7.1.0 on ubuntu 20.10 / Gnome 3.38.1

I honestly have no idea what is causing this, but in your case I would try to backup the config files (these are located in ~/.local/share/YACReader under the respective app directories) and relaunch on a fresh config. If the problem persists, there is a problem with your user configuration, if not, there is an issue with the YACReader config.

Whoaouh. Impressive response time. I've just found it myself and was about to update my post. By the way, it has worked. PB is fixed. I'll analyze the config detail to try to find the problem.
Thanks for the support.

So...
After investigation and contrary to my first thoughts, nothing to do with the .ini file, let alone the .log
For some reason, il that .local/share/YACReader/YACReader directory I have a file called bookmarks.yacr

It's a binary file I cannot edit nor identify to what kind of "bookmarm" it corresponds to but for sure if I replace it in the directory, I get the core dump again and when I remove it I am back to normal. So probably a temp file which should have been deleted when the application closes and for some reason it did not and as it correspond to some comics I had open at the time but I am trying to read a different one, it fails.
Might be worth investigating the code protection.

As I want to study the opportunity to design a light server running on a NAS and only supporting "access" request (no library management), I'll see if I can identify where it is in the code.

This is from the reader's bookmark management. Remove the file, open a comic and set a bookmark using the bookmark symbol (right symbol from the lens). Try if you can trigger the error by closing the app and reloading it.

I don't know how Luis designed the bookmark system, but there is a builtin preview feature (that probably is the binary part) and somehow loading that stuff seems to trigger your segfault.